NIST

TM*T L INST. OF STAND i TECH

PUBLICATIONS AlllQb 33qfll3

Computer

Systems

Technology

u s DEPARTMENT OF

COMMERCE

National Institute of Standards and

Technology

NIST Special Publication 500-177

Stable Implementation Agreements for

Open Systems Interconnection Protocols

Version 3 Edition 1

December 1989

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

NIST Workshop Chairman

Tim Boland, NIST

NIST Special Publication 500-177

Stable Implementation Agreements for

Open Systems Interconnection Protocols

Version 3 Edition 1

December 1989

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

Workshop Chairman

Tim Boland, NIST

NIST

i' PUBLICATIONSi

Computer

Systems

Technology

U.S. DEPARTMENT OF

COMMERCE

National Institute of Standards and

Technology

Nisr NAT L INST, OF STAND & TECH R.I.C,

A111D3 MMbl3E

NIST Special Publication 500-177

Stable Implementation Agreements for

Open Systems Interconnection Protocols

Version 3 Edition 1

December 1989

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

Workshop Chairman

Tim Boland. NIST

Special Interest Group (SIG) Chairs

U.S. DEPARTMENT OF COMMERCE

Robert A. Mosbacher, Secretary

NATIONAL INSTITUTE OF STANDARDS

AND TECHNOLOGY

John W. Lyons, Director

Directory Sen/ices

FTAM

Lower Layers

Manufacturing Message Spec.

Network Management

ODA

Registration Authority

Remote Database Access

Security

Transaction Processing

Upper Layers

Virtual Terminal

X400

Chris Moore

Klaus Truoei

Fred Burg

Herbert Faik

Paul Brusii Frank Dawson

Einard Stefferud Richard Gerhardt

James M. Galvin

Andrew P. Schwartz

David Chappeii

Cyndi Jung

Barbara Nelson

Touch Communications

DFN

AT&T

SISCO

MITRE

IBM

NMA-Northrup

General Motors

Trusted info. Sys.

IBM Corp.

Cray Research

3COM

RETIX

Supersedes NIST/SP-500/162

Issued March 1990
Reports on Computer Systems Technology

The National Institute of Standards and Teclinology (NIST) {formerly tlie National Bureau of Standards)

has a unique responsibility for computer systems technology within the Federal government. NIST's

National Computer Systems Laboratory (NCSL) develops standards and guidelines, provides technical

assistance, and conducts research for computers and related telecommunications systems to achieve more effective utilization of Federal information technology resources. NCSL's responsibilities include

development of technical, management, physical, and administrative standards and guidelines for the

cost-effective security and privacy of sensitive unclassified information processed in Federal computers.

NCSL assists agencies in developing security plans and in improving computer security awareness training. This Special Publication 500 series reports NCSL research and guidelines to Federal agencies as well as to organizations in industry, government, and academia.

National Institute of Standards and Technology Special Publication 500-177

Natl. Inst. Stand. Technol. Spec. Publ. 500-177, 679 pages (Mar. 1990)

CODEN: NSPUE2

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1990

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, DC 20402
September 1990 (Stable)

Table of Contents

1. GENERAL INFORMATION 1 1.1 PURPOSE OF THIS DOCUMENT 1 1.2 PURPOSE OF THE WORKSHOP 2 1.3 WORKSHOP ORGANIZATION 3 1.4 USE AND ENDORSEMENT BY OTHER ENTERPRISES 3 1.5 RELATIONSHIP OF THE WORKSHOP TO THE NIST 3 1.6 STRUCTURE AND OPERATION OF WORKSHOP 4

1.6.1 Plenary 4

1.6.2 Special Interest Groups 4

1.7 POINTS OF CONTACT 4

1.8 PROFILE CONFORMANCE 4

1.8.1 General Principle 4

1.8.2 Constraints 5 1.8.2.1 Sending/Encoding Entity 5 1.8.2.2 Receiving/Decoding Entity 5 1.8.3 Classification of Conformance 6

2. SUB NETWORKS

2.1 INTRODUCTION

2.2 SCOPE AND FIELD OF APPLICATION

2.3 STATUS

2.4 ERRATA

2 . 5 LOCAL AREA NETWORKS

2.5.1 IEEE 802.2 Logical Link Control

2.5.2 IEEE 802.3 CSMA/CD Access Method 2 2.5.3 IEEE 802.4 Token Bus Access Method 3 2.5.4 IEEE 802.5 Token Ring Access Method 4

2.5.5 Fiber Distributed Data Interface (FDDI) 5 2.5.5.1 Token Ring Media Access Control (MAC, X3.139-

1987) 5 2.5.5.2 Token Ring Physical Level (PHY, X3 . 148- 1988) . 5 2.5.5.3 Physical Layer Media Dependent (PMD, X3.166-

1989) 5 2.6 WIDE AREA NETWORKS 5 2.6.1 CCITT Recommendation X.25 6

2.6.2 ISO 7776 6

2.6.3 ISO 8208 6 2.7 INTEGRATED SERVICES DIGITAL NETWORKS (ISDN) 7 2.7.1 Introduction 7 2.7.2 Implementation Agreements 8 2.7.2.1 Physical Layer, Basic Access at "U" 10

2.7.2.2 Physical Layer, Basic Access at S and T . . . 10

2.7.2.3 Physical Layer, Primary Rate at "U" 10

2.7.2.4 Data Link Layer, D-Channel 12

2.7.2.5 Signaling 12

2.7.2.6 Data Link Layer, B-Channel 13

2.7.2.7 Packet Layer .... 13

2.8 APPENDIX A 14

iii
September 1990 (Stable)

2.8.1 Data Link Layer, D-Channel 14

2.8.2 Signaling 14

2.9 BIBLIOGRAPHY 15

3. NETWORK LAYER

3.1 INTRODUCTION

3.2 SCOPE AND FIELD OF APPLICATION

3.3 STATUS

3.4 ERRATA

3.5 CONNECTIONLESS -MODE NETWORK SERVICE (CLNS)

3.5.1 ISO 8473 . . . . 3.5.2 Provision of CLNS over Local Area Networks (LANS) 4

3.5.3 Provision of CLNS over X.25 Subnetworks 5 3.5.4 Provision of CLNS over ISDN 5 3.5.4.1 CLNP Utilizing X.25 Services 5

3.5.5 Provision of CLNS over Point- to-Point Links ... 6

3.6 CONNECTION-MODE NETWORK SERVICE (CONS) 6

3.6.1 Mandatory Method of Providing CONS 6

3.6.1.1 General 6

3.6.1.2 X.25 WAN 6

3.6.1.3 LANs . . . . 7

3.6.1.4 ISDN 7 3.6.2 Additional Option: Provision of CONS over X.25

1980 Subnetworks 7 3.6.3 Agreements on Protocols 7 3.6.3.1 ISO 8878 7 3.6.3.2 Subnetwork Dependent Convergence Protocol

(ISO 8878/Annex A) 7

3.6.4 Interworking

.

8

3.7 ADDRESSING 8

3.8 ROUTING 8

3.8.1 End System to Intermediate System Routing .... 9

3.8.2 Intermediate Systems to Intermediate Systems

Routing 13

3.9 PROCEDURES FOR OSI NETWORK SERVICE/PROTOCOL IDENTIFICATION . 14

3.9.1 General 14

3.9.2 Processing of Protocol Identifiers 14

3.9.2.1 Originating NPDUs 15

3.9.2.2 Destination System Processing 16

3.9.2.3 Further Processing in Originating End System 17

3.9.3 Applicable Protocol Identifiers 17

3.10 MIGRATION CONSIDERATIONS . 18

3.10.1 X. 25-1980 18

3.11 USE OF PRIORITY 19

3.11.1 Introduction 19

3.11.2 Overview 19

3.12 CONFORMANCE 19

3.13 BIBLIOGRAPHY 19

TRANSPORT

IV
September 1990 (Stable)

4.1 INTRODUCTION 1 4.2 SCOPE AND FIELD OF APPLICATION ....... 1 4.3 STATUS 1 4.4 ERRATA 1 4.5 PROVISION OF CONNECTION MODE TRANSPORT SERVICE 1 4.5.1 Transport CLASS 4 2

4.5.1.1 Transport Class 4 Overview 2

4.5.1.2 Protocol Agreements . 2

4.5.1.2.1 General Rules 2

4.5.1.2.2 Transport Class 4 Service Access Points

or Selectors 3

4.5.1.2.3 Retransmission Timer 4

4.5.1.2.4 Keep -Alive Function 5

4.5.1.2.5 Congestion Avoidance Policies 7

4.5.1.2.6 Use of Priority 10

4.5.2 Transport Class 0 10

4.5.2.1 Transport Class 0 Overview 11

4.5.2.2 Protocol Agreements 11

4.5.2.2.1 Transport Class 0 Service Access Points 11

4.5.2.3 Rules for Negotiation 11

4.5.3 Transport Class 2 12

4.5.3.1 Transport Class 2 Overview 12

4.5.3.2 Protocol Agreements ..... 12

4.6 PROVISION OF CONNECTIONLESS TRANSPORT SERVICE ....... 12

4.6.1 Connectionless Transport Overview 13

4.6.2 Protocol Agreements . , 13

4.6.2.1 Connectionless Transport Service Access

Points or Selectors 13

4.7 TRANSPORT PROTOCOL IDENTIFICATION . . 13

5. UPPER LAYERS 1 5.1 INTRODUCTION 1 5.1.1 References ...... 1 5.2 SCOPE AND FIELD OF APPLICATION 1 5.3 STATUS 1 5.4 ERRATA 1 5.4.1 ISO Defect Solutions 1 5.4.2 Session Defect Solutions Correcting CCITT X.215

and X. 225 2

5.4.3 Errata approved at March, 1990 meeting ...... 2

5.5 ASSOCIATION CONTROL SERVICE ELEMENT 3

5.5.1 Introduction 3

5.5.2 Services 3

5.5.3 Protocol Agreements ..... 3

5.5.3.1 Application Context ... 3

5.5.3.2 AE Title 3

5.5.4 ASN.l Encoding Rules 3

5.5.5 Connectionless 3

5.5.6 Resulr. Parameter 4

5.6 ROSE 4

V
September 1990 (Stable)

5.7 RISE 4

5.8 PRESENTATION .....

4

5.8.1 Introduction 4

5.8.2 Service ...... 4

5.8.3 Protocol Agreements 5

5.8.3.1 Transfer Syntaxes . . 5

5.8.3.2 Presentation Context Identifier . . 5

5.8.3.3 Default Context , 5

5.8.3.4 P-Selectors 5

5.8.3.5 Provider Abort Parameters 6

5.8.3.6 Provider Aborts and Session Version 6

5.8.3.7 CPC-Type . 6

5.8.3.8 Presentation-context-definition-result-list . 6

5.8.3.9 RS-PPDU 7 5.8.4 Presentation ASN.l Encoding Rules . 7 5.8.4.1 Invalid Encoding 7

5.8.5 General 7

5.8.5.1 Presentation Data Value (PDV) 7

5.8.6 Connection Oriented ........ 7 5.8.7 Connectionless 8

5.9 SESSION

,.

. . 8

5.9.1 Introduction 8

5.9.2 Services 8

5.9.3 Protocol Agreements ... 9

5.9.3.1 Concatenation ... 9

5.9.3.2 Segmenting 9

5.9.3.3 Reuse of Transport Connection 9

5.9.3.4 Use of Transport Expedited Data 9

5.9.3.5 Use of Session Version Number 9

5.9.3.6 Receipt of Invalid SPDUs .......... 10

5.9.3.7 Invalid SPM Intersections .......... 11

5.9.3.8 S-Selectors 11

5.9.4 Connectionless , 11

5.10 UNIVERSAL ASN . 1 ENCODING RULES 11

5.10.1 TAGS 11

5.10.2 Definite Length 11

5.10.3 EXTERNAL 11

5.10.4 Integer 12

5.10.5 String Types 12

5.10.6 Bit String 12

5.11 CHARACTER SETS 13

5.12 CONFORMANCE 13

5.12.1 Specific ASE Requirements ..... 13

5.12.1.1 FTAM 13

' 5.12.1.1.1 Phase 2 13

5.12.1.2 MHS 17

5.12.1.2.1 Phase 1 (1384 X.400) . . 17

5.12.1.2.2 Phase 2, Protocol PI (1988 X.400) . 18

5.12.1.2.3 Phase 2, Protocol P7 (1988 X.4G0) . 19

5.12.1.2.4 Phase 2, Protocol P3 (1988 X.400) . 22

vi
September 1990 (Stable)

5.12.1.3 DS 22

5.12.1.3.1 Phase 1 22

5.12.1.4 Virtual Terminal . 24

5.12.1.4.1 Phase la 24

5.12.1.4.2 Phase lb .... 25

5.12.1.5 MMS 26

5.12.1.6 Transaction Processing 27

5.13 APPENDIX A: RECOMMENDED PRACTICES 28

5.14 APPENDIX B: OBJECT IDENTIFIER REGISTER 32

5.14.1 Register Index 32

5.14.2 Object Identifier Descriptions 32

REGISTRATION AUTHORITY PROCEDURES FOR THE OSI IMPLEMENTORS

WORKSHOP 1 6.1 INTRODUCTION AND SCOPE 1 6.1.1 What is Registration? 1 6.1.2 Scope 2

6.2 REGISTERED INFORMATION OBJECTS 2

6.3 REGISTRATION PROCEDURES FOR OBJECT IDENTIFIERS 4

6.3.1 SIC Registration Authorization 4

6.3.2 SIG Registration Authority Function and Duties . . 4

6.3.3 Requirements for Information Object Registration . 5 6.3.3.1 Assignment of Object Identifier Component

Values 5 6.3.3.2 Proposal of Object and Identifier to Plenary 5 6.3.3.3 Completion of Registration Procedure .... 6

6. 3. 3. 4 Changes and Revisions to the Information

Object Registration 6

6.3.4 Register Index 6

6.4 APPENDIX A: ASSIGNMENTS TO WORKSHOP ORGANIZATIONS .... 7 6.5 APPENDIX B: STATUS OF 1987 AND 1988 AD-HOC OBJECT

IDENTIFIERS 8

CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM 1 7 . 1 INTRODUCTION 1 7.2 SCOPE 2

7.3 STATUS 3

7.4 EF-RATA 3

7.5 PRMD to PPJ4D 3

7.5.1 Introduction 3

7.5.2 Service Elements and Optional User Facilities . . 4

7.5.2.1 Classification of Support for Services ... 4

7.5.2.1.1 Support (S) 5 7.5.2.1.2 Non Support (N) 6

7.5.2.1.3 Not Used (^/U) 6

7.5.2.1.4 Not Applicable (N/A) 6

7.5.2.2 Summary of Supported Services ........ 6

7.5.2.3 MT Service Elements and Optional User

Facilities 6

vii
September 1990 (Stable)

7.5.2.4 IPM Service Elements and Optional User

Facilities 8

7.5.3 X.400 Protocol Definitions 11

7.5.3.1 Protocol Classification 11

7.5.3.2 General Statements on Pragmatic Constraints . 12

7.5.3.3 MPDU Size 12

7.5.3.4 PI Protocol Elements 12

7.5.3.4.1 PI Envelope Protocol Elements ..... 12

7.5.3.5 ORName Protocol Elements ... 17

7.5.3.6 P2 Protocol Profile (Based on [X.420]) ... 19

7.5.3.6.1 P2 Protocol - Heading 20

7.5.3.6.2 P2 Protocol - BodyParts 22

7.5.3.6.3 P2 BodyPart Protocol Elements ..... 24

7.5.4 Reliable Transfer Server (RTS) .... 26

7.5.4.1 Implementation Strategy 26

7.5.4.2 RTS option selection 26

7.5.4.3 RTS Protocol Options and Clarifications ... 27

7.5.4.4 RTS Protocol Limitations 30

7.5.5 Use of Session Services ....... 32

7.5.6 Data Transfer Syntax 32

6 PRMD to ADMD and ADMD to ADMD 32

7.6.1 Introduction 32

7.6.2 Additional ADMD Functionality 34

7.6.2.1 Relay Responsibilities of an ADMD ...... 34

7.6.2.2 PI Protocol Classification Changes 35

7.6.2.3 0/R Names 35

7.6.2.4 PI ADMD Name 36

7.6.3 Interworking with Integrated UAs . 36

7.6.4 Differences with Other Profiles , . 37

7.6.4.1 TTC Profile 37

7.6.4.2 CEPT Profile 37

7.6.5 Connection of PRMDs to Multiple ADMDs ...... 37

7.6.6 Connection of an ADMD to a Routing PRMD ..... 38

7.6.7 Management Domain Names 38

7.6.8 Envelope Validation Errors ..... 38

7.6.9 Quality of Service 39

7.6.9.1 Domain Availability ........ 39

7.6.9.1.1 ADMD Availability 39

7.6.9.1.2 PRMD Availability 40

7.6.9.2 Delivery Times 40

7.6.10 Billing Information ..... 41

7.6.11 Transparency 42

7.6.12 RTS Password Management ..... 42

7.6.13 For Further Study 43

7 INTER and INTRA PRMD CONNECTIONS 43

7.7.1 Introduction 43

7.7.2 The Relaying PRMD 44

7.7.2.1 Relay Responsibilities of a PRMD 44

7.7.2.2 Interaction with an ADMD 44

7.7.3 Intra PRMD Connections 45

viii
September 1990 (Stable)

7.7.3.1 Relay Responsibilities of an MTA 45

1 .1 .1) .1 Loop Suppression within a PRMD 46

7.7.3.3 Routing Within a PRMD 47

7.7.3.3.1 Class Designations 47

7.7.3.3.2 Specification of MTA Classes 49

7.7.3.3.3 Consequences of Using Certain Classes of

MTAs 49

7.7.3.4 Uniqueness of MPDUidentifiers Within a PRMD . 50

7.7.4 Service Elements and Optional User Facilities . . 51

7.7.5 X.400 Protocol Definitions 51

7.7.5.1 Protocol Classification 51

7.7.5.2 PI Protocol Elements 51

7.7.5.3 Reliable Transfer Server (RTS) 54

7.8 ERROR HANDLING 54

7.8.1 MPDU Encoding 55

7.8.2 Contents 55

7.8.3 Envelope 55

7.8.3.1 Pragmatic Constraint Violations 55

7.8.3.2 Protocol Violations 55

7.8.3.3 0/R Names 56

7.8.3.4 Tracelnformation 56

7.8.3.5 InternalTracelnfo 57

7.8.3.6 Unsupported X.400 Protocol Elements 57

7.8.3.6.1 DeferredDelivery 58

7.8.3.6.2 PerDomainBilaterallnfo 58

7.8.3.6.3 ExplicitConversion 58

7.8.3.6.4 AlternateRecipientAllowed 58

7.8.3.6.5 ContentReturnRequest 58

7.8.3.7 Unexpected Values for INTEGER Protocol

Elements 58

7.8.3.7.1 Priority 59

7.8.3.7.2 ExplicitConversion 59

7.8.3.7.3 ContentType ... 59

7.8.3.8 Additional Elements 59

7.8.4 Reports 59

7.9 MHS USE OF DIRECTORY SERVICES 60

7.9.1 Directory Service Elements 60

7.9.2 Use of Names and Addresses 61

7.10 CONFORMANCE 61

7.10.1 Introduction 62

7.10.2 Definition of Conformance 62

7.10.3 Conformance Requirements 64

7.10.3.1 Introduction 64

7.10.3.2 Initial Conformance 64

7.10.3.2.1 Interworking 65

7.10.3.2.2 Service 65

7.11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS . . 66

7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES 70

7.12.1 Recommended Practices in P2 70

7.12.2 Recommended Practices in RTS 70

ix
September 1990 (Stable)

7.12.3 Recommended Practices for ORName 71

7.12.4 Postal Addressing 74

7.12.5 EDI use of X.400 75

7.12.5.1 Introduction and Scope 75

7.12.5.2 Model 75

7.12.5.3 Protocol Elements Supported for EDI 77

7.12.5.4 Addressing and Routing 77

7.12.6 USA Body Parts 78

7.12.7 Recommended Practices for Binary Data

Transfer 78

7.12.8 Recommended Practice for Office Document

Architecture (ODA) Transfer 79

7.13 APPENDIX C: RENDITION OF IA5Text AND T61String CHARACTERS 80

7.13.1 Generating and Imaging IA5Text 80

7.13.2 Generating and Imaging T61String 80

7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED

THROUGH 81

7.14.1 Encoding of RTS User Data 81

7.14.2 Extra Session Functional Units 81

7.14.3 Mixed Case in the MTA Name 82

7.14.4 X.410 Activity Identifier 82

7.14.5 Encoding of Per Recipient Flag and Per Message

Flag 82

7.14.6 Encoding of Empty Bitstrings 83

7.14.7 Additional Octets for Bitstrings 83

7.14.8 Application Protocol Identifier .... 83

7.14.9 Initial Serial Number in S-Connect 83

7.14.10 Connection Data on RTS Recovery 84

7.14.11 Activity Resume 84

7.14.12 Old Activity Identifier 84

7.14.13 Negotiation Down to Transport Class 0 84

7.15 APPENDIX E: WORLDWIDE X.400 CONFORMANCE PROFILE MATRIX . 85

7.16 APPENDIX F: INTERWORKING WARNINGS 97

MESSAGE HANDLING SYSTEMS 1 8.1 INTRODUCTION 1 8.2 SCOPE 2 8.3 STATUS 5

8.4 ERRATA 5

8.5 MT KERNEL 5

8.5.1 Introduction 5

8.5.2 Elements of Service 6

8.5.3 MTS Transfer Protocol (PI) 9

8.5.4 MTS - APDU Size 9

8.5.5 1988/84 Interworking Considerations 9

8.6 IPM KERNEL 10

8.6.1 Introduction 10

8.6.2 Elements of Service 10

8.6.3 Interpersonal Messaging Protocol (P2) 13

8.6.4 Body Part Support 13

X
September 1990 (Stable)

8.7 MESSAGE STORE 15

8.7.1 Introduction 15

8.7.2 Scope 16

8.7.3 Elements of Service 17

8.7.4 Attribute Types 17

8.7.5 Pragmatic Constraints for Attribute Types .... 18

8.7.6 Implementation of the MS with 1984 Systems .... 18

8.7.7 MS Access Protocol (P7) 18

8.7.8 MTS Access Protocol (P3) 19

8.8 REMOTE USER AGENT SUPPORT 19

8.8.1 Introduction 20

8.8.2 Scope 20

8.8.3 Elements of Service 20

8.8.4 MTS Access Protocol (P3) 21

8.9 NAMING, ADDRESSING AND ROUTING 22

8.10 MHS MANAGEMENT 22

8.11 MHS SECURITY 22

8.12 SPECIALIZED ACCESS 22

8.13 CONVERSION 22

8.14 USE OF UNDERLYING LAYERS 22

8.14.1 MTS Transfer Protocol (PI) 22

8.14.2 MTS Access Protocol (P3) and MS Access Protocol

(P7) 22

8.15 ERROR HANDLING 23

8.16 CONFORMANCE 23

8.17 APPENDIX A; MHS PROTOCOL SPECIFICATIONS 25

8.17.1 MTS Transfer Protocol (PI) 28

8.17.2 Interpersonal Messaging Protocol (P2) 37

8.17.3 MTS Access Protocol (P3) 40

8.17.4 MS Access Protocol (P7) 50

8.17.5 Message Store General Attribute Support 56

8.17.6 Message Store IPM Attribute Support 58

8.18 APPENDIX B: INTERPRETATION OF ELEMENTS OF SERVICE .... 60

8.19 APPENDIX C: RECOMMENDED PRACTICES 61

8.19.1 Printable String 61

8.19.2 Rendition of IA5Text 62

8.19.3 EDI 63

8.19.3.1 Introduction and Scope 63

8.19.3.2 Model 64

8.19.3.3 Protocol Elements Supported for EDI 64

8.19.3.4 Addressing and Routing 65

8.19.4 Textual Representation of O/R Names 66

8.20 APPENDIX D: LIST OF ASN.l OBJECT IDENTIFIERS 66

8.20.1 Content Types . 66

8.20.2 Body Part Types 66

9. ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 2 1 9.1 INTRODUCTION 1 9.2 SCOPE AND FIELD OF APPLICATION 1 9.3 STATUS 2

xi
September 1990 (Stable)

9.4 ERRATA 4

9.5 ASSUMPTIONS 5 9.6 PRESENTATION AGREEMENTS 7 9.7 SERVICE CLASS AGREEMENTS 7 9.8 FUNCTIONAL UNIT AGREEMENTS 7 9.9 FILE ATTRIBUTE AGREEMENTS 7 9.9.1 Mandatory Group 8

9.9.2 Optional Groups 9

9.10 DOCUMENT TYPE AGREEMENTS 9

9.10.1 Character Sets ....... 12

9.10.1.1 ISO 646 Character Set ... 13

9.10.1.2 Format Effectors 15

9.10.1.3 8859-1 Character Set 15

9.10.2 Document Type Negotiation Rules 15

9.10.2.1 Connection Establishment 15

9.10.2.2 File Creation 15

9.10.2.3 File Opening . 16

9.10.3 Relationship Between DUs , DEs and Document Types . 17

9.11 F-CANCEL ACTION 17

9.12 IMPLEMENTATION INFORMATION AGREEMENTS 18

9.13 DIAGNOSTIC AGREEMENTS 18

9.14 CONCURRENCY 20

9.15 REQUESTED ACCESS 20

9.16 SECURITY 21

9.16.1 Initiator Identity and Filestore Password ... 21

9.16.2 Access Passwords ... 21

9.16.3 Implementation Responsibilities 21

9.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS 21

9.17.1 Interoperable Configurations ..... 22

9.17.2 Relationship to ISO 8571 --The FTAM Standard ... 23

9.17.3 Requirements for Document Type Support 23

9.17.4 Initiators 23

9.17.5 Responders 25

9.17.6 Senders 26

9.17.6.1 Initiator Senders 26

9.17.6.2 Responder Senders . 27

9.17.7 Receivers . 27

9.17.7.1 Initiator Receivers 27

9.17.7.2 Responder Receivers 28

9.17.8 Minimum Ranges 28

9.17.9 Range of Values for INTEGER Type Parameters ... 30

9.17.10 Use of Lower Layer Services 31

9.18 IMPLEMENTATION PROFILES 31

9.18.1 General Requirements for the Defined

Implementation Profiles 32

9.18.2 (deleted) 32

9.18.3 Document Type Requirements for the Defined

Implementation Profiles 32

9.18.4 Parameters for the Defined Implementation Profiles 34

xii
September 1990 (Stable)

9.18.5 Parameter Ranges for the Defined Implementation

Profiles 34

9.18.6 File Attribute Support for Implementations .... 34

9.19 PROVISION OF SPECIFIC FUNCTION 37

9.19.1 Implementation Profile Tl : Simple File Transfer . 37

9.19.2 Implementation Profile T2 : Positional File

Transfer 37

9.19.3 Implementation Profile T3: Full File Transfer . . 38

9.19.4 Implementation Profile Al : Simple File Access . . 38

9.19.5 Implementation Profile A2: Full File Access ... 39

9.19.6 Implementation Profile Ml: Management 40

9.20 HARMONIZATION 40

APPENDIX A: FTAM DOCUMENT TYPES 42

A.l NBS-6 Sequential file document type 42

A. 2 NBS-7 Random Access File 42

A. 3 NBS-8 Indexed Sequential File 42

A. 4 NBS-9 File Directory File 42

A. 5 NBS-6 Sequential file document type 42-1

A. 6 NBS-7 Random access file 47

A. 7 NBS-8 Indexed sequential file 53

A. 8 NBS-9 File directory file 59

APPENDIX B: CONSTRAINT SETS 62-1

B. l NBS Ordered Flat Constraint Set 62-1

B. 2 NBS Ordered Flat Constraint Set Definition 63

APPENDIX C: ABSTRACT SYNTAXES 65-1

C. l Abstract Syntax NBS-ASl 65-1

C.2 Abstract Syntax NBS-AS2 65-1

C.3 Abstract Syntax NBS-ASl Definition 66

C.4 Abstract Syntax NBS-AS2 Definition 67

C.5 Abstract Syntax "FTAM unstructured text abstract syntax" . . 67

C.6 Abstract Syntax "FTAM unstructured binary abstract syntax" . 67

ISO FILE TRANSFER, ACCESS AND MANAGEMENT PHASE 3 1 10.1 INTRODUCTION 1 10.2 SCOPE AND FIELD OF APPLICATION 2

10.3 STATUS 2

10.4 ERRATA 5

10.5 CONFORMANCE 5

10.5.1 Conformance for Access Profiles 6

10.6 ASSUMPTIONS 6

10.7 FILESTORE AGREEMENTS 6

10.7.1 Document Types 6

10.7.2 FADU Identities 9

10.7.3 Access Control Attribute 10

10.8 PROTOCOL AGREEMENTS 10

10.8.1 Implementation Profile Ml . 3 10

10.8.2 Functional Units 10

10.8.3 Implementation Information Parameter 10

10.8.4 F-Check 11

10.8.5 Error Recovery 11

xiii
September 1990 (Stable)

10.8.5.1 Docket Handling 11

10.8.5.2 Parameters for Error Recovery 11

10.8.6 Concurrency Control 12

10.8.6.1 Concurrency Control to whole file 12

10.8.6.2 FADU Locking 12

10.8.7 Create Password 13

10.8.8 Initiator Identity, Passwords and Account .... 13

10.9 RANGE OF VALUES FOR INTEGER-TYPE PARAMETER 13

APPENDIX A: PROFILES REQUIREMENTS LIST FOR NIST OIW 15

APPENDIX B: NIST OIW REGISTER OF FTAM OBJECTS 64

APPENDIX C: DOCUMENT TYPES 67

APPENDIX D: CONSTRAINT SETS 83

APPENDIX E: ABSTRACT SYNTAXES ... 86

DIRECTORY SERVICES PROTOCOLS 1 11.1 INTRODUCTION 1 11.2 SCOPE AND FIELD OF APPLICATION 1 11.3 STATUS 2

11.4 USE OF DIRECTORY 2 11.5 DIRECTORY ASES AND APPLICATION CONTEXTS 4

11.6 SCHEMA 4

11.6.1 Support of Structures and Naming Rules 4

11.6.2 Support of Object Classes and Subclasses 5

11.6.3 Support of Attribute Types 5

11.6.4 Support of Attribute Syntaxes 5

11.6.5 Naming Contexts 5 11.6.6 Common Profiles 5 11.6.6.1 OIW Directory Common Application Directory

Profile 6

11.6.6.1.1 Standard Application Specific

Attributes and Attribute Sets ... 6

11.6.6.1.2 Standard Application Specific

Object Classes 6

11.6.6.2 OIW Directory Strong Authentication Directory

Profile 6

11.6.6.2.1 Other Profiles Supported 6

11.6.6.2.2 Standard Application Specific

Object Classes 7 11.6.7 Restrictions on Object Class Definitions 7

11.7 PRAGMATIC CONSTRAINTS 7 11.7.1 General Constraints 7 11.7.1.1 Character Sets 7 11.7.1.2 APDU Size Considerations 7 11.7.1.3 Service Control (SC) Considerations 8

11.7.1.4 Priority Service Control 8

11.7.2 Constraints on Operations 8

11.7.2.1 Filters 8

11.7.2.2 Errors 9

11.7.2.3 Error Reporting - Detection of Search Loop. . 9

11.7.3 Constraints Relevant to Specific Attribute Types . 9

xiv
September 1990 (Stable)

11.8 CONFOEIMANCE 10

11.8.1 DUA Conformance 10

11.8.2 DSA Conformance 11

11.8.3 DSA Conformance Classes 11

11.8.4 Authentication Conformance 12

11.8.5 Directory Service Conformance 13

11.8.6 The Directory Access Profile 14

11.8.7 The Directory System Profile 15

11.8.8 Digital Signature Protocol Conformance Profiles. . 15

11.8.9 Strong Authentication Protocol Conformance Profile 15

11.9 DISTRIBUTED OPERATIONS 15

11.9.1 Referrals and Chaining 15

11.9.2 Trace Information 16

11.10 UNDERLYING SERVICES 16

11.10.1 ROSE 16

11.10.2 Session 16

11.10.3 ACSE 16

11.11 ACCESS CONTROL 16

11.12 TEST CONSIDERATIONS 16

11.12.1 Major Elements of Architecture 17

11.12.2 Search Operation 17

11.13 ERRORS 17

11.13.1 Permanent vs. Temporary Service Errors 18

11.13.2 Guidelines for Error Handling 18

11.13.2.1 Introduction 18

11.13.2.2 Symptoms 18

11.13.2.3 Situations 18

11.13.2.4 Error Actions 19

11.13.2.5 Reporting 19

11.14 SPECIFIC AUTHENTICATION SCHEMAS 19

11.14.1 Specific Strong Authentication Schemes 20

11.14.1.1 ElGamal 20

11.14.1.1.1 References 20

11.14.1.1.2 Background 21

11.14.1.1.3 Digital Signature 21

11.14.1.1.4 Verification 22

11.14.1.1.5 Known Constraints on Parameters . . 22

11.14.1.1.6 Note on subj ectPublicKey 23

11.14.1.2 One-Way Hash Functions 23

11.14.1.2.1 SQUARE-MOD-N Algorithm 23

11.14.1.2.2 MD2 Algorithm 24

11.14.1.2.3 Study of Other One-Way Hash

Functions 24

11.14.1.2.4 Use of One-Way Hash Functions in

Forming Signatures. ... 24

11.14.1.3 ASN.l for Strong Authentication Algorithms

Signatures 24

11.14.1.4 Note on the ENCRYPTED MACRO 25

11.14.2 Protected Simple Authentication 25

11.14.3 Simple Authentication 25-1

XV
September 1990 (Stable)

11.15 APPENDIX A: Maintenance of Attribute Syntaxes 26

11.15.1 Introduction 26

11.15.2 General Rules . 26

11.15.3 Checking Algorithms 26

11.15.3.1 distingui she dNameSyntax 26

11.15.3.2 integerSyntax 26

11.15.3.3 telephoneNumberSyntax 27

11.15.3.4 countryName 27

11.15.3.5 preferredDeliveryMethod , , . 27

11.15.3.6 presentationAddress 27

11.15.4 Matching Algorithms . 27

11.15.4.1 UTCTimeSyntax . 27

11.15.4.2 distinguishedNaraeSyntax 27

11.15.4.3 caselgnoreListSyntax 28

11.16 APPENDIX B Glossary ..... 28

11.17 Appendix C: Requirements for Distributed Operations .... 29

11.17.1 General Requirements 29

11.17.2 Protocol Support 29

11.17.2.1 Usage of ChainingArguments 29

11.17.2.2 Usage of ChainingResults 30

11.18 APPENDIX D: Guideline for Applications Using the

Directory 30

11.18.1 Tutorial , 30

11.18.1.1 Overview 30

11.18.1.2 Use of the Directory Schema 30

11.18.1.2.1 Use of Existing Object Classes. . . 30

11.18.1.2.2 Kinds of Object Classes 31

11.18.1.2.3 Use of Unregistered Object Classes. 31

11.18.1.2.4 Side Effects of Unregistered

Object Classes. . 32

11.18.2 Creation of New Object Classes 33

11.18.2.1 Creation of New Subclasses 33

11.18.2.2 Creation of New Attributes 33

11.18.3 DIT Structure Rules. ... 34

11.19 APPENDIX E: Template for an Application Specific

Profile for Use of the Directory .... 34

12. SECURITY 1 12.1 Definitions 1 12.2 Matrix of Security Services and OSI Layers 2

13. FUTURE SECURITY 1

14. ISO VIRTUAL TERMINAL PROTOCOL ..... 1 14.1 INTRODUCTION 1 14.2 SCOPE AND FIELD OF APPLICATION ....... 1 14.2.1 Phase la Agreements ... 1 14.2.2 Phase lb Agreements 1 14.2.3 Phase II Agreements . . ...... 2

14.3 STATUS .......... .... 2

14.3.1 Status of phase la 2

xvi
September 1990 (Stable)

14.3.2 Status of phase lb 2

14.3.3 Status of phase II 2

14.4 ERRATA 2

14.5 CONFORMANCE 4

14.6 PROTOCOL 6

14.6.1 Protocol Elements 6

14.6.2 Mapping of Protocol Elements 6

14.6.3 Protocol Data Unit Structure 6

14.7 OIW REGISTERED CONTROL OBJECTS 6

14.7.1 Sequenced Application (SA) 6

14.7.1.1 Entry Number 6

14.7.1.2 Name of Sponsoring Body 7 14.7.1.3 Date 7 14.7.1.4 Identifier 7

14.7.1.5 Descriptor Value 7 14.7.1.6 CO Parameters

. 7 14.7.1.7 CO Values and Semantics 7 14.7.1.8 Additional Information 8

14.7.1.9 Usage 8

14.7.2 Unsequenced Application (UA) 8

14.7.2.1 Entry Number 8

14.7.2.2 Name of Sponsoring Body 8

14.7.2.3 Date 8

14.7.2.4 Identifier 8

14.7.2.5 Descriptor Value 8

14.7.2.6 CO Parameters 9

14.7.2.7 CO Values and Semantics 9

14.7.2.8 Additional Information 9

14.7.2.9 Usage 9

14.7.3 Sequenced Terminal (ST) 9

14.7.3.1 Entry Number 9

14.7.3.2 Name of Sponsoring Body 9

14.7.3.3 Date 9

14.7.3.4 Identifier 10

14.7.3.5 Descriptor Value 10

14.7.3.6 CO Parameters 10

14.7.3.7 CO Values and Semantics 10

14.7.3.8 Additional Information 11

14.7.3.9 Usage 11

14.7.4 Unsequenced Terminal (UT) 12

14.7.4.1 Entry Number 12

14.7.4.2 Name of Sponsoring Body 12

14.7.4.3 Date 12

14.7.4.4 Identifier 12

14.7.4.5 Descriptor Value 12

14.7.4.6 CO Parameters 12

14.7.4.7 CO Values and Semantics 12

14.7.4.8 Additional Information 13

14.7.4.9 Usage 13

14.8 OIW DEFINED PROFILES 13

xvii
September 1990 (Stable)

14.8.1 Telnet Profile 13

14.8.1.1 Introduction 13

14.8.1.2 Association Requirements 13

14.8.1.2.1 Functional Units 13

14.8.1.2.2 Mode 13

14.8.1.3 Profile Body 13

14.8.1.4 Profile Arguments 16

14.8.1.5 Profile dependent Control Object Information 17

14.8.1.6 Profile Notes . 17

14.8.1.6.1 Definitive Notes 17

14.8.1.6.2 Informative Notes . 20

14.8.1.7 Specific Conformance Requirements 20

14.8.2 Transparent Profile . . 20

14.8.2.1 Introduction 20-1

14.8.2.2 Association Requirements 21

14.8.2.2.1 Functional Units 21

14.8.2.2.2 Mode 21

14.8.2.3 Profile Body 21

14.8.2.4 Profile Arguments 22

14.8.2.5 Profile dependent Control Object Information 22

14.8.2.6 Profile Notes 22

14.8.2.7 Specific Conformance Requirements 22

14.8.3 Forms Profile 22

14.8.3.1 Introduction 23

14.8.3.2 Association Requirements 23

14.8.3.2.1 Functional Units 23

14.8.3.2.2 Mode 23

14.8.3.3 Profile Body 24

14.8.3.4 Profile Arguments 47

14.8.3.5 Profile Dependent Control Objects 52

14.8.3.5.1 Sequenced Application CO 52

14.8.3.5.2 Unsequenced Application CO ... , 52

14.8.3.5.3 Sequenced Terminal CO 52

14.8.3.5.4 Unsequenced Terminal CO 52

14.8.3.6 Profile Notes 52

14.8.3.6.1 Definitive Notes 52

14.8.3.6.2 Informative Notes 58

14.8.3.7 Specific Conformance Requirements 59

14.8.4 X3 Profile 59

14.8.4.1 Introduction 59

14.8.4.2 Association Requirements 59

14.8.4.2.1 Functional Units 59

14.8.4.2.2 Mode 59

14.8.4.3 Profile Body 59

14.8.4.4 Profile Arguments 66

14.8.4.5 Profile Notes 67

14.8.4.5.1 Definitive Notes 67

14.8.4.5.2 Informative Notes 73

14.8.4.6 Specific Conformance Requirements 75

14.9 APPENDIX A 76

xviii
September 1990 (Stable)

14.9.1 Specific ASE Requirement 76

14.10 APPENDIX B 76

14.10.1 Defaults 76

14.11 APPENDIX C - OBJECT IDENTIFIERS 76

15. TRANSACTION PROCESSING 1

16. OFFICE DOCUMENT ARCHITECTURE 1 16.1 INTRODUCTION 1 16.2 SCOPE AND FIELD OF APPLICATION 1 16.3 REFERENCES 2

16.4 DEFINITIONS AND ABBREVIATIONS 4

16.5 POSITION OF THIS DAP IN THE TAXONOMY OF RELATED DAPS .... 4

16.6 CONFORMANCE 5

16.6.1 Data stream conformance 5 16.6.2 Implementation conformance 6

16.7 CHARACTERISTICS SUPPORTED BY THIS DAP 6

16.7.1 Overview 6

16.7.1.1 Specification of constituents 6

16.7.1.2 Formatted form documents 7 16.7.1.3 Processable Form Documents 7 16.7.1.4 Formatted Processable Form Documents .... 7

16.7.2 Logical characteristics 8

16.7.2.1 Document logical structure 8

16.7.2.2 Document structure elements 9

16.7.2.2.1 Document 9

16.7.2.2.2 Passage 9

16.7.2.2.3 Numbered Segment 9

16.7.2.2.4 Paragraph 10

16.7.2.2.5 Phrase 11

16.7.2.2.6 Figure 11

16.7.2.2.7 Footnote 11

16.7.2.2.8 Footnote reference 11

16.7.2.2.9 Reference 12

16.7.3 Layout characteristics 12

16.7.3.1 Document layout structure 12

16.7.3.2 Document layout structure elements 12

16.7.3.2.1 Document 13

16.7.3.2.2 Page set 13

16.7.3.2.3 Page layout 13

16.7.3.2.4 Body area layout 13

16.7.3.2.5 Header area layout 14

16.7.3.2.6 Footer area layout 15

16.7.3.2.7 Header contents and footer contents 16

16.7.3.2.8 Page numbering 16

16.7.3.2.9 Layout of document logical contents 16

16.7.3.2.10 Layout of passage (or segment)

contents 16

16.7.3.2.11 Layout of passage contents .... 17

16.7.3.2.12 Layout controls 17

xix
September 1990 (Stable)

16.7.3.2.13 Layout of paragraph contents ... 20

16.7.3.2.14 Layout of figure contents 20

16.7.3.2.15 Layout of footnote contents .... 21

16.7.4 Content characteristics 21

16.7.4.1 Character content 21

16.7.4.1.1 Character repertoire 21

16.7.4.1.2 Character presentation 22

16.7.4.1.3 Character set features and

control functions 22

16.7.4.2 Raster graphics content 22

16.7.4.3 Geometric graphics content 22

16.7.5 Miscellaneous features 22

16.7.5.1 Resources 23

16.7.6 Document management features 23

.8 SPECIFICATION OF CONSTITUENT CONSTRAINTS 23

16.8.1 Document profile 23

16.8.1.1 Macro Definitions 23

16.8.1.2 Document profile constraints 25

16.8.1.2.1 Presence of document

constituents 25

16.8.1.2.2 Document characteristics 26

16.8.1.2.3 Document management attributes . . 27

16.8.2 Logical Constituent Constraints 27

16.8.2.1 Diagrams of Relationships of Logical

Constituents 27

16.8.2.2 Macro definitions 30

16.8.2.3 Factor constraints 31

16.8.2.4 Logdoc : ANY-LOGICAL { 32

16.8.2.5 Passage : COMP-LOGICAL { 33

16.8.2.6 NumberedSegment : COMP-LOGICAL { 33

16.8.2.7 Number : BASIC-LOGICAL { 33

16.8.2.8 Title : COMP-LOGICAL { 34

16.8.2.9 TitleT : COMP-LOGICAL { 34

16.8.2.10 Paragraph : COMP-LOGICAL { 34

16.8.2.11 Phrase : COMP-LOGICAL { 34

16.8.2.12 PhraseF : COMP-LOGICAL { 35

16.8.2.13 FNote : COMP-LOGICAL { 35

16.8.2.14 FNBody : COMP-LOGICAL { 35

16.8.2.15 Figure : COMP-LOGICAL { 35

16.8.2.16 Text : BASIC -LOGICAL { 36

16.8.2.17 Reference : COMP-LOGICAL { 36

16.8.2.18 Ref : BASIC-LOGICAL { 36

16.8.2.19 Raster : BASIC-LOGICAL { 37

16.8.2.20 Geometric : BASIC-LOGICAL { 37

16.8.2.21 CommonContent { 37

16.8.2.22 PageNumber { 38

16.8.3 Layout Constituent Constraints 38

16.8.3.1 Diagrams of Relationships of Layout

Constituents 38

16.8.3.2 Macro definitions 41

XX
September 1990 (Stable)

16.8.3.3 Factor constraints 42

16.8.3.4 Laydoc :ANY-LAYOUT { 43

16.8.3.5 PageSet :ANY-LAYOUT { 43

16.8.3.6 Page :ANY-PAGE { 43

16.8.3.7 RPage :ANY-PAGE { 44

16.8.3.8 VPage :ANY-PAGE { 44

16.8.3.9 Header : ANY-FRAME { 44

16.8.3.10 Footer : ANY-FRAME { 45

16.8.3.11 BodyFramel : ANY-FRAME { 45

16.8.3.12 BodyFranie2 : ANY-FRAME {....... 46

16.8.3.13 FrameA : ANY-FRAME { 46

16.8.3.14 Frames : ANY-FRAME { 47

16.8.3.15 FrameC : ANY-FRAME { 47

16.8.3.16 FrameD : ANY-FRAME { 48

16.8.3.17 FrameE :A1JY-FRAME { 48

16.8.3.18 FrameF :ANY-FPJ^E { 49

16.8.3.19 FrameG : ANY-FRAME { 49

16.8.3.20 FrameH : ANY-FRAME { 50

16.8.3.21 Framel : ANY-FRAME { 50

16.8.3.22 FraraeJ : ANY-FRAME { 51

16.8.3.23 FrameK : ANY-FRAME { 51

16.8.3.24 Block :ANY-LAYOUT { 51

16.8.4 Layout style constraints ..... 52

16.8.4.1 Factors 52

16.8.4.2 LStylel : ANY- LAYOUT -STYLE { . 52

16.8.4.3 LStyle2 : ANY-LAYOUT -STYLE { 53

16.8.4.4 LStyle3 : ANY-LAYOUT -STYLE { 53

16.8.4.5 LStyle4 :A1^Y- LAYOUT-STYLE { 53

16.8.4.6 LStyleS :AITY- LAYOUT -STYLE { . 53

16.8.4.7 LStyle6 : ANY-LAYOUT-STYLE ( 54

16.8.5 Presentation style constraints 54

16.8.5.1 Macros 54

16.8.5.2 Factors 56

16.8.5.3 PStylel : ANY- PRESENTATION- STYLE { . . . . 56

16.8.5.4 PStyle2 : ANY- PRESENTATION- STYLE { . . . . 56

16.8.5.5 PStyle3 : ANY- PRESENTATION- STYLE { . . . . 56

16.8.5.6 PStyle4 : ANY- PRESENTATION- STYLE { . . . . 56

16.8.6 Content portion constraints 57

16.8.6.1 Character content portion 57

16.8.6.2 P».aster graphics content portion . 58

16.8.6.3 Geometric graphics content portion 58

16.8.7 Additional usage constraints ... 58

16. S INTERCHANGE FORMAT 58

16.9.1 ASN.l generation constraints 58

16.9.2 ASN.l parsing constraints ... 58

16.9.3 ASN.l generation recommendations .... 59

16.9.3.1 Ordering of set members 59

16.9.4 ASN.l parsing recommendations 59

16.9.4.1 Encoding of application comments 59

16.10 AMEX A IMPLEMENTATION CONFORMANCE STATEMENT 60

XXi
September 1990 (Stable)

16.10.1 Generator support statement proforma 60

16.10.2 Receiver support statement proforma 60

16.11 ANNEXE INFORMATIVE RECOMMENDATIONS 60

16.11.1 Overview of technical specifications 60

16.11.2 ISO 8632 (CGM) constraints for this DAP 62

16.11.2.1 Delimiter elements 63

16.11.2.2 Metafile description elements 63

16.11.2.3 Picture descriptor elements 63

16.11.2.4 Control elements 63

16.11.2.5 Graphical primitive elements 64

16.11.2.6 Attribute elements 64

16.11.2.7 External Elements 65

16.11.3 Interoperability with SGML Applications 67

17. FUTURE OFFICE DOCUMENT ARCHITECTURE (ODA) 1

18. FUTURE NETWORK MANAGEMENT 1 18.1 INTRODUCTION 1 18.1.1 References 1 18.2 SCOPE AND FIELD OF APPLICATION 2

18.3 STATUS 2

18.4 ERRATA 2

18.5 MANAGEMENT FUNCTIONS AND SERVICES 3

18.6 MANAGEMENT COMMUNICATIONS. .... 3

18.6.1 Association Policies 3

18.6.2 General Agreements on Users of CMIS 3

18.6.2.1 Object Naming 3

18.6.2.2 Multiple Object Selection 3

18.6.2.2.1 Scoping 3

18.6.2.2.2 Filtering 3

18.6.2.2.3 Synchronization 4

18.6.2.2.4 Multiple Replies 4

18.6.2.3 Current/Event Time 4

18.6.2.4 Access Control 4

18.6.2.5 CMIS Functional Units 4

18.6.2.6 CMIS Parameters 4

18.6.3 Specific Agreements on Users of CMIS 5

18.6.3.1 M- Event-Report 5

18.6.3.1.2 Parameter Agreements 5

18.6.3.2 M-Get 6

18.6.3.2.1 Successful Response 6

18.6.3.2.2 Partially Successful or Unsuccessful Response 6

18.6.3.2.3 Multiple Replies 7

18.6.3.2.4 Parameter Agreements 7

18.6.3.3 M-Set

....

7

18.6.3.3.1 Successful Response 8

18.6.3.3.2 Partially Successful or Unsuccessful Response 8

18.6.3.3.3 Multiple Replies 8

xxii
September 1990 (Stable)

18.6.3.3.4 Add/Remove Response 8

18.6.3.3.5 Parameter Agreements 8

18.6.3.4 M-Action 9

18.6.3.4.1 Multiple Objects 9

18.6.3.4.2 Parameter Agreements 10

18.6.3.5 M-Create 10

18.6.3.5.1 Managed Object Instance 10

18.6.3.5.2 Attribute Values 11

18.6.3.5.3 Parameter Agreements 11

18.6.3.6 M-Delete 11

18.6.3.6.1 Deletion of Objects Containing

Objects 12

18.6.3.6.2 Parameter Agreements 12

18.6.4 Specific Agreements on CMIP 12

18.6.4.1 Invoke/Linked Identifier Size 13

18.6.4.2 Version 13

18.6.4.3 Linked Reply Values 13

18.6.4.4 Error Codes 13

18.6.5 Services Required by CMIP 13

18.7 MANAGEMENT INFOPKATION 13

19. REMOTE DATABASE ACCESS (RDA) 1

20. MANUFACTURING MESSAGE SPECIFICATION (MMS) 1

21. REFERENCES 1 21.1 CCITT 1 21.2 ISO 4

21.3 Additional References 12

21.4 IEEE 12

21.5 NBS 13

21.6 MAP 14

21.7 TOP 14

21.8 CEN/CENELEC 14

21.9 SPAG 15

21.10 ANSI 15

xxiii
September 1990 (Stable)

List of Figures

Figure 2 . 1 LSAP bit pattern 1 Figure 2.2 I~Field Format .....

5

Figure 2.3 Protocol Layers at S, T and U reference points when D

Channel is used in ISDN 9

Figure 2.4 Protocol Layers at S, T and U reference points when B

Channel is used in ISDN 10

Figure 4.1 AK exchange on idleconnection . 7 Figure 6.1 Structure of Object Identifier for OIW 3

Figure 6.2 Structure of an Object Identifier for an example

object for the Registration Authority SIG of OIW ... 4

Figure 7.1 The layered structure of this implementation agreement 2 Figure 7.2 This agreement applies to the interface between: (A)

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

and (D) MTA and MTA 3

Figure 7.3 Interconnection of private domains . 4

Figure 7.4 X.409 Definition of Privately Defined BodyParts .... 23

Figure 7.5 An ADMD may (b) or may not (a) serve as a relay .... 34

Figure 7.6 Relaying PRMD 44

Figure 7.7 Intra PRMD connections 45

Figure 7.8 MD C must know of A to route the message 45

Figure 7 . 9 Definition of InternalTracelnfo ...... 46

Figure 7.10 Defined Actions in MTASuppliedlnfo 47

Figure 7.11 Example of a configuration to be avoided 50

Figure 8.1 Scenario Definition ....... 3

Figure 8,2 MHS Functional Groups . 4

Figure 8.5 Privately-Defined Body Parts 15

Figure 8.6 Message Store Model ...... 16

Figure 8.7 Scope of Message Store Agreements 16

Figure 8 . 8 Scope of Remote User Agent Agreements .... 20

Figure 8.10 MT Kernel Conformance Classes 25

Figure 8.11 EDI Messaging Functional Model 64

Figure 9.1 Model of file transfer/access 2

Figure 11.1 Structure of this Implementation Agreement 1 Figure 11.2 Centralized Directory Model .... 3

Figure 11.3 Distributed Directory Model 3

Figure 11.4 APDU Exchange 8

Figure 11.5 Logical DSA Application Environment 9

Figure 11.6 Three Ways of Creating Two Object Classes 32

Figure 14.1 Conformance Status for VT Facilities 4

Figure 16.1: Examples of layout within body area . 15

Figure 16.2: Example of text flow around figure 18

Figure 16.3: Example of synchronized text. ....... 19

Figure 16.4: Diagram of logical structure (1 of 4) . 27

Figure 16.5: Diagram of logical structure (2 of 4) ........ . 28

Figure 16.6: Diagram of logical structure (3 of 4) 28

Figure 16.7: Diagram of logical structure (4 of 4) 29

Figure 16.8: Diagram of Layout Structure (1 of 4) 38

Figure 16.9: Diagram of Layout Structure (2 of 4) 39

XXiv
September 1990 (Stable)

Figure 16.10: Diagram of Layout Structure (3 of 4) 40

Figure 16.11: Diagram of Layout Structure (4 of 4) 41

XXV
September 1990 (Stable)

List of Tables

Table 2.1 ANSI-CCITT Cross-References 15

Table 3.1 Queue Length Averaging Algorithm 4

Table 3.2 End Systems Communications 13

Table 5.1 Session States 26

Table 5.2 Incoming Events 27

Table 7.1 Basic MT service elements 7

Table 7.2 MT optional user facilities provided to the UA-selectable

on a per-message basis 7 Table 7.3 MT optional user facilities provided to the UA agreed for

any contractual period of time 8

Table 7.4 Basic IPM service elements 9

Table 7.5 IPM optional facilities agreed for a contractual period of

time 9

Table 7.6 IPM optional user facilities selectable on a per-message

basis 10

Table 7.7 Protocol Classifications 11

Table 7.8 PI protocol elements 13

Table 7.9 ORName protocol elements 18

Table 7.10 P2 heading protocol elements 20

Table 7.11 P2 BodyParts 24

Table 7.12 Checkpoint window size of IP 30

Table 7.13 RTS protocol elements 31

Table 7.14 PI Protocol Classification Changes for a Delivering ADMD . 35

Table 7.15 Delivery Time Targets 41

Table 7.16 Forced Nondelivery Times 41

Table 7.17 Conformant MTA Classifications 48

Table 7.18 PI Protocol Elements 52

Table 7B.1 Printable string to ASCII mapping 73

Table 7E.1 Protocol element comparison of RTS 86

Table 7E.2 Protocol element comparison of Pi 88

Table 7E.3 Protocol element comparison of P2 93

Table 8.1 MT Kernel: Basic MT Elements of Service 7 Table 8.2 MT Kernel: MT Service Optional User Facilities 8

Table 8.3 Application Contexts Classification 9

Table 8.4 IPM Kernel: Basic IPM Elements of Service 11

Table 8.5 IPM Kernel: IPM Service Optional User Facilities 12

Table 8.6 IPM Kernel: Body Part Types 14

Table 8.7 Message Store: Elements of Service 17

Table 8.8 Application Contexts Support for P7 19

Table 8.9 Application Contexts Support for P3 19

Table 8.10 Remote User Agent Support: MT Elements of Service .... 21

Table 8.11 Remote User Agent Support: IPM Elements of Service .... 21

Table 8.12 Application Contexts Support for P3 21

Table 8.23 Conformance Requirements 24

Table 8.24 Classification Changes 26

Table 8.25 Classification of the PI Protocol Elements 28

Table 8.26 Classification of the P2 Protocol Elements 37

Table 8.27 Classification of the P3 Protocol Elements 40

XXVi
September 1990 (Stable)

Table 8.28 Classification of the P7 Protocol Elements 50

Table 8.29 Classification of the Message Store General Attributes . . 56

Table 8.30 Classification of the Message Store IPM Attributes .... 58

Table 8.31 Printable String to ASCII Mapping 61

Table 8.32 Interpretation of Format Effector Combinations 63

Table 9.1 Parameters for FTAM-1, -2,-3 10

Table 9.2 Parameters for NBS-6, NBS-7, NBS-8 11

Table 9.3 FTAM primitive data types 12

Table 9.4. IRV Graphic Character Allocations 14

Table 9.5 Interoperable configurations 23

Table 9.6 Required minimal parameter support 29

Table 9.7 Implementation profile support requirements 36

Table 9.8 Implementation Profiles (NIST) and Profiles

(SPAG/CEN-CLC) 40

Table 9.9 Information objects in NBS-6 43

Table 9.10 Information objects in NBS-7 48

Table 9.11 Information objects in NBS-8 53

Table 9.12 Datatypes for keys 56

Table 9.13 Information objects in NBS-9 60

Table 9.14 Basic constraints for NBS Ordered flat 64

Table 9.15 Identity constraints in NBS Ordered flat 65

Table 10.0 Phase 2/Phase 3 Interworking 3

Table 10.1 Implementation Profiles and Document Types 7 Table 10.2 Information objects in NBS-10 66

Table 10.3 Information Objects in NBS-11 70

Table 10.4 Datatypes for keys 72

Table 10.5 Information objects in NBS-1 76

Table 10.6 Basic Constraints in the NBS Random Access Constraint Set 82

Table 10.7 Identity Constraints in the NBS Random Access Constraint

Set 83

Table 11.1 Pragmatic Constraints for Selected Attributes

Part 1 of 2) 36

Table 11.1 Pragmatic Constraints for Selected Attributes

(Part 2 of 2) 37

Table 11.2 Directory Access Service Support 38

Table 11.3 DAP Protocol Support (Part 1 of 7) 39

Table 11.3 DAP Protocol Support (Part 2 of 7) 40

Table 11.3 DAP Protocol Support (Part 3 of 7) 41

Table 11.3 DAP Protocol Support (Part 4 of 7) 42

Table 11.3 DAP Protocol Support (Part 5 of 7) 43

Table 11.3 DAP Protocol Support (Part 6 of 7) 44

Table 11.3 DAP Protocol Support (Part 7 of 7) 45

Table 11.4 Directory System Service Support 46

Table 11.5 DSP Protocol Support (Part 1 of 9) 47

Table 11.5 DSP Protocol Support (Part 2 of 9) 48

Table 11.5 DSP Protocol Support (Part 3 of 9) 49

Table 11.5 DSP Protocol Support (Part 4 of 9) 50

Table 11.5 DSP Protocol Support (Part 5 of 9) 51

Table 11.5 DSP Protocol Support (Part 6 of 9) 52

Table 11.5 DSP Protocol Support (Part 7 of 9) 53

xxvii
September 1990 (Stable)

Table 11.5 DSP Protocol Support (Part 8 of 9) 54

Table 11.5 DSP Protocol Support (Part 9 of 9) 55

Table 11.6 DAP Support for Digital Signature Protocol Conformance

Profile 56

Table 11.7 DSP Support for Digital Signature Protocol Conformance

Profile 56

Table 11.8 DAP Support for Strong Authenticatione Protocol

Conformance Profile 57

Table 11.9 DSP Support for Strong Authenticatione Protocol

Conformance Profile 58

Table 11.10 Error Symptoms (Part 1 of 3) 61

Table 11.10 Error Symptoms (Part 2 of 3) 62

Table 11.10 Error Symptoms (Part 3 of 3) 63

Table 11.11 Error Situations 64

Table 11.12 Notation Used to Describe Error Actions 65

Table 11.13 Error Actions (Part 1 of 6) 66

Table 11.13 Error Actions (Part 2 of 6) 67

Table 11.13 Error Actions (Part 3 of 6) 68

Table 11.13 Error Actions (Part 4 of 6) 69

Table 11.13 Error Actions (Part 5 of 6) 70

Table 11.13 Error Actions (Part 6 of 6) 71

Table 11.14 Simple Credential Fields and Protected Simple

Authentication 73

Table 14.1 Sets of Conflicting FEIs 33

Table 14.2 Local actions that move entry location 54

Table 20-1 Table MMS Service Subset 7

xxviii
1. GENERAL INFORMATION

September 1990 (Stable)

1.1 PURPOSE OF THIS DOCUMENT

This document records current stable implementation agreements of OSI

protocols among the organizations participating in the NIST Workshop

for Implementors of OSI. Stable in the context of this document

means that

1) The agreements are based on final standards

(e.g., ISO-IS or CCITT Recommendations) or nearly final (e.g., ISO-DIS) with no significant changes expected, and,

2) The agreements have been approved by the NIST

Workshop Plenary for progression from the

Working Agreements document to this document

after a period of review. These agreements are considered final; the only changes allowed will

be clarifications, and certain Technical and

Alignment errata. These changes must have the

strong support of vendors, and be justifiable.

For these reasons, the agreements are considered advanced enough for use in product and test suite development. This means that readers can use this text as a basis for procurement references for OSI

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

.

Future releases of these Stable Agreements will add and/or extend

functionality offered by this edition and version. When required, new

versions will be introduced on a yearly basis. It is the NIST

Workshop intent that new versions of this Stable Agreements document

will be compatible with the present version. If this proves

impractical, the agreements will attempt to provide mechanisms and

guidelines which maximize interoperability. Furthermore, it is the

intent that these stable agreements be maintained via the Errata

process as long as is appropriate. For the subject area, interworking

information and other useful advice to the reader is given as appropriate. Specific "defect report" information (including extent

of applicability) is provided in the ERRATA portions of each Chapter.

Agreements text is either in this Stable Document (Stable) or in the

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

for sec. 1). New editions of a version reflect very recent stable

functionality as well as editorial, technical, and alignment errata,

all applied to the previous edition.

1-1
September 1990 (Stable)

The intended audience for this document is composed of those

individuals who are interested in Stable Implementation Agreements for

OSI protocols. Each section of the document covers a different

subject area, and the sections are presented so as to present a consistent and unified approach. The structure of each section,

whenever possible, is divided into the following subsections:

o Introduction,

o Scope and Field of Application,

o Status,

o Errata,

o Protocol and Service Agreements,

o Conformance , and

o Appendices.

The corresponding and aligned document, "Working Implementation

Agreements for OSI Protocols dated September 1990," records agreements

which are not yet considered stable, in the sense described above.

This document will be referenced as the "Working Agreements

Document." This Stable document is aligned with the Working

Agreements Document in the sense that the structures are identical,

and pointers are given in this Stable Document to work in the Working

Agreements Document which could become stable in the future.

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

accounting of current stable agreements. Minor changes (Errata) to

these agreements will be issued in replacement page format as separate

editions. These errata will only be applied to the current version.

Version 3 (this version) is backwards compatible with Version 2 to the

maximum extent possible. Version 3 includes all of the material from

Version 2, (modified by errata) as well as now stable material from

the previous year; important new functional additions from Version 2 are in the areas of certain aspects of Lower Layers network

technology, X.3 Virtual Terminal profile, Workshop Registration

procedures, new Upper Layer and Directory Services agreements, and new

FTAM and 1988-Based X.400 agreements.

1.2 PURPOSE OF THE WORKSHOP

In February, 1983, at the request of industry, NIST organized the NIST

Workshop for Implementors of OSI to bring together future users and

potential suppliers of OSI protocols. The Workshop accepts as input

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

these protocols. This process is expected to expedite the development

of OSI protocols and promote interoperability of independently

manufactured data communications equipment.

1-2
September 1990 (Stable)

1.3 WORKSHOP ORGANIZATION

The Workshop organizes its work through Special Interest Groups

(SIGs) that prepare technical documentation. An executive committee

of SIG chairpersons led by the overall Workshop chairperson

administers the Workshop. NIST invites highly qualified technical

leaders from participating organizations to assume leadership roles in

the SIGs. The SIGs are encouraged to coordinate with standards

organizations and user groups, and to seek widespread technical

consensus on implementation agreements through international

discussions and liaison activities.

The Workshop meets four times a year at the National Institute of

Standards and Technology in Gaithersburg , Maryland where each SIG is

required to convene its meeting. In addition, a plenary assembly of

all Workshop delegates is convened for consideration of SIG motions

and other Workshop business. SIGs are also encouraged to hold interim

meetings at varied locations around the world.

The Workshop is an open public forum. Registration materials,

documents, and Workshop schedules are available from:

National Institute of Standards and Technology

NIST Workshop for Implementors of OSI

Building 225, Room B-217

Gaithersburg, Maryland 20899

1.4 USE AND ENDORSEMENT BY OTHER ENTERPRISES

The Workshops are held for those organizations expressing an interest

in implementing or procuring OSI Protocols and Open Systems. However,

there is no corporate commitment to implementations associated with

Workshop participation.

The Workshop and associated agreements have been endorsed by various

activities and groups. See the aligned section of the Working

Agreements Document for more on this subject.

1.5 RELATIONSHIP OF THE WORKSHOP TO THE NIST

As resources permit, NIST, with voluntary assistance from industry,

develops formal protocol specifications, reference implementations,

tests, and test systems for the protocols agreed to in the Workshops.

The NIST organizes, administers, and makes technical contributions to

the Workshop. The NIST bears no other relation to the workshop.

1-3
September 1990 (Stable)

1.6 STRUCTURE AND OPERATION OF WORKSHOP

1.6.1 Plenary

The main body of the workshop is a Plenary Assembly. Any

organization may participate. Representation is international.

The NIST prefers for the business of Workshops to be conducted

informally since there are no corresponding formal commitments

within the Workshop to implement the decisions reached. For more

information, consult the aligned section of the Working

Agreements Document.

1.6.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 during

the Workshop week. As technical work is completed by a SIG, it

is presented to the Plenary for disposition. For more

information on SIGs (including SIG charters), consult the aligned

section of the Working Agreements Document.

1.7 POINTS OF CONTACT

For information concerning the workshop, write to:

Chair, NIST Workshop for Implementors of OSI

at the address given in section 1.3.

Individual points of contact are given in the aligned section of the

Working Agreements Document.

1.8 PROFILE CONFORMANCE

This section presents general concepts for profile conformance. These

concepts shall be obseirved when writing Implementation Agreements.

1.8.1 General Principle

Conformance to an OSI Profile (Implementation Agreements,

Functional Standards) implies conformance to the referenced Base

Standards

.

1-4
September 1990 (Stable)

Therefore, a Profile shall not specify any requirements that

would contradict or cause non- conformance to the Base Standards

to which it refers (see TR 10000-1, clauses 6.1, 6.3.1). The

conformance requirements defined in ISO/IEC TR 10000-1 fully

apply.

1.8.2 Constraints

Base standards usually provide options for PDUs , parameters,

encoding choices, value ranges, etc.

A profile may make specific choices of these options and ranges

of values. For the promotion of interoperability, pragmatic

constraints or minimum requirements may be imposed (e.g., the

limitation of Search operations, selection of encoding choices,

value ranges , byte ranges for encoding) . These minimum

requirements of restrictions shall not contradict the

conformance requirements of the respective base standards.

1 8 2 1 Sending/Encoding Entity

In order to promote interworking , reasonable restrictions or minimum requirements may be specified in a profile as described above

.

1.8.2.2 Receiving/Decoding Entity

Minimum requirements of receiving/decoding capability for

alternatives, permissible values, etc. may be specified in a profile. A profile shall not specify the behavior of a receiving/decoding entity when receiving data which is

outside the scope of or excluded by the Profile for senders.

A Profile Conformance Test shall be limited by the scope of

the profile specification and shall not probe beyond its

boundaries. That means, the capability of a receiver/decoder would be tested only in the range of

choices or values which are specified for the

sending/encoding entity (i.e., for interworking between

systems both being conformant to the Profiles)

.

1-5
September 1990 (Stable)

1.8.3 Classification of Conformance

Conformance requirements of a profile shall be related to

conformance requirements of a base standard as written in clause

6.5 and annnex C of ISO/IEC TR 10000-1. For the conformance

classes, the following terminology shall be used unless

otherwise specified by the base standard or equivalent

conformance requirements for a profile as required by the ISO/IEC

Technical Committee that is responsible for the base standard:

m mandatory

0 optional

c conditional

X excluded

1 out of scope

not applicable

1-6
September 1990 (Stable)

2^ SUB NETWORKS

Editor's Note: The term "Ongoing" used in this document refers to the

I Working Implementation Agreements dated September 1990.

2.1 INTRODUCTION

This chapter provides agreements about subnetwork services used in

support of the OSI Network Layer.

2.2 SCOPE AND FIELD OF APPLICATION

These agreements cover subnetwork types including local area networks,

packet switched networks, circuit switched networks, ISDN, and others.

2.3 STATUS

This version was completed in March 1990. Updated material has been

moved into section 2.5.2 from the Working Implementation Agreements

Document to replace existing text.

2.4 ERRATA

2.5 LOCAL AREA NETWORKS

2.5.1 IEEE 802.2 LOGICAL LINK CONTROL

The following decisions have bean reached with respect to this

protocol

.

1. Link Service Access Point (LSAP)

The code below shall be used to address systems using

Network Layer protocols identified by ISO TR 9577 (e.g., ISO

8473, ISO 8208). 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

j 1 1 1

2-1
September 1990 (Stable)

Figure 2.1. LSAP bit pattern.

Type and Class

Only the connectionless type 1, class 1 IEEE 802 link

service will be used.

2.5.2 IEEE 802.3 CSMA/CD ACCESS METHOD

The following implementation agreements have been reached with

respect to the IEEE 802.3 CSMA/CD Access Method and Physical

Layer Specifications:

o The address length shall be 48 bits

o For a data packet of LLC data length of n octets, the

length of the pad field is

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

The following implementation agreements have been reached with

respect to 10 BROAD 36 Networks:

1. Single Cable Networks

The translator frequency shall be 192.25 Mhz

The channel allocations are

Reverse Channels Forward Channels

T12, T13, T14

T13, T14, 2'

T14, 2' , 3'

2' , 3' , 4'

3' , 4' , 4A'

4' , 4A' , 5'

L, M, N

M, N, 0

N, 0, P

0, P, Q

P, Q, R

Q. R, S

2-2
December ' 89

2. Dual Cable Networks

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

channel allocations are:

T12, T13, T14

T13, T14, 2' T14, 2' , 3' 2' , 3' , 4'

3' , 4' , 4A'

4' , 4A' , 5' L, M, N

M, N, 0

N, 0, P

0, P, Q

Q, R, S

3. When both IEEE 802.4 and IEEE 802.3 10 BROAD 36

networks coexist on the broadband cable system the

preferred channel allocations are:

Reverse Forward

IEEE 802.3 T12, T13, T14 L, M, N

IEEE 802.4 6' , FMl' T, U

channels 3' , 4' P, Q

reserved for 4A' , 5' R, S future use

2.5.3 IEEE 802.4 TOKEN BUS ACCESS METHOD

The following options are agreed to with respect to Draft J of

token bus

:

o Data Rate:

10 Mb (Broadband)

5 Mb (Carrierband)

o Addressing: 48 bit

o The ImeOption, Priority Mechanism, shall be implemented

2-3
December ' 89

Broadband Channel Assignments

Forward Reverse

P 3' Q 4'

R 4A'

S 5' T 6'

U FMl

2.5.4 IEEE 802.5 TOKEN RING ACCESS METHOD

The following implementation agreements have been reached with

respect to the IEEE Standard 802.5, Token Passing Ring Access

Method and Physical Layer specification.

o The data signalling rate shall be 4 Mbit/s

o The address length shall be 48 bits

o The message priority (PM) of the AMP data unit shall be

7

o The ALL_STATIONS_THIS_RING_ADDRESS shall be

X'COOOFFFFFFFF'

o The TRR value shall be 4 milliseconds

o The THT value shall be 8 . 9 milliseconds

o The TQP value shall be 20 milliseconds

o The TVX value shall be 10 _ milliseconds

.o The TNT value shall be 2 . 6 milliseconds

o The TAM value shall be 7 seconds

o The TSM value shall be 15 seconds

2-4
December ' 89

o The MAC Information field (I-field) shall be defined as follows

:

Starting Sequence I-Field End Sequence

and the

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

2) Ending Sequence includes: FCS , ED, FS

Figure 2.2. I-Field Format.

With the above timer and MAC I-field definitions, the

following limits are defined:

Protocol limits the I-field to a maximum of 4425

bytes , and

All stations shall support I-fields that have a minimum of one byte and a maximum of at least 2000

bytes

.

2.5.5 FIBER DISTRIBUTED DATA INTERFACE (FDDI)

2.5.5.1 Token Ring Media Access Control (MAC. X3. 139-1987)

(Refer to the Ongoing Implementation Agreements

Document)

2.5.5.2 TOKEN RING PHYSICAL LEVEL ( PHY , X3 . 148 - 1988

)

(Refer to the Ongoing Implementation Agreements

Document)

2.5.5.3 PHYSICAL LAYER MEDIA DEPENDENT (PMD. X3. 166- 1989)

(Refer to the Ongoing Implementation Agreements

Document)

2.6 WIDE AREA NETWORKS

2-5
December '89

2.6.1 CCITT RECOMMENDATION X.25

The procedures required to describe the DTE side of a DTE/DCE

interface for systems attached to sub-networks providing an X.25

interface shall be as defined in ISO 7776 and ISO 8208 and as supplemented below. (These procedures shall also apply to a DTE

operating on a DTE/DTE interface).

2.6.2 ISO 7776

ISO 7776 is used as the Layer 2 Protocol with the agreements

defined below.

1 The address assignments are:

DTE = A (=11000000 binary)

DCE = B (=10000000 binary)

On a DTE/DTE interface, one of the DTEs , by a prior

agreement, shall use the DCE address.

2 The modulus shall be 8.

3 A window size (k) of 7 shall be supported. In

addition, other window sizes may also be supported.

4 The Multilink Procedures are excluded.

2.6.3 ISO 8208 ^ .

The elements of ISO 8208 applicable for use depend on the OSI

role of ISO 8208 (ie,, provision of CONS, support of CLNP)

.

Independent of the role, ISO 8208 is used as the Layer 3 protocol, with the following agreements:

1 Virtual Call Service,

2 any mutually agreed window and packet size, however,

all DTEs must be capable of supporting a window size of

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

modulus of 8

,

S-* a DTE must be capable of receiving the Flow Control

Parameter Negotiation Facility and responding

appropriately (per ISO 8208) , and

2-6
December ' 89

4 The Basic RPOA Selection Facility shall be implemented

and its use or non-use selectable on a per virtual call

basis

.

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

\^^hen ISO 8208 is used to support CLNP (when providing the CLNS),

Permanent Virtual Circuit Service may also be used.

2.7 INTEGRATED SERVICES DIGITAL NETWORKS (ISDN)

2.7.1 Introduction

This section defines Implementation Agreements for packet-data

transfer in an ISDN context. The agreements provide a set of

procedures for accessing an ISDN so that end systems implemented

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

.

The agreements are not meant to preclude vendors from

implementing additional procedures as long as they do not create

system interoperability problems. Capabilities will vary from

ISDN to ISDN and procedures beyond those included here may be

necessary to request and utilize network services more effectively and fully.

The agreements cover two fundamental ISDN services for X.25

packet mode ISDN terminals, namely,

CASE I: The ISDN provides a circuit-mode (Layer 1)

connection either on demand ("switched") or permanently ("dedicated circuit"). A general

description of the corresponding ISDN 64 Kbps

circuit-mode bearer service is described in CCITT

Recommendation 1.231. The circuit-mode

connection is between an X.25 ISDN terminal and

(i) a PSPDN, or (ii) another X.25 ISDN terminal.

The circuit-mode connection to a PSPDN

corresponds to CASE A of CCITT Recommendation

X.31.

CASE II: The ISDN provides the X.25 virtual circuit

service. A general description of this service is

given in CCITT Recommendation 1.232. This case corresponds to CASE B of CCITT Recommendation

X.31.

2-7
December '89

Figures 2.3 and 2.4 give the agreed stacks for X.25 packet

transfer over D and B channels, respectively. Some particular

aspects are given below.

1. The packet data transfer is on a B channel of a Basic

Access or a Primary Rate Interface. In CASE II, it can

be on a D channel of a Basic Access Interface.

2. The layer 2 procedures are LAPB (ISO 7776) on a B

channel and LAPD (CCITT Recommendation Q.921) on a D

channe 1

.

3. X.25 PLP (ISO 8208) procedures are used, including the

setting up and clearing of virtual calls.

4. Q.921 and Q.931 procedures on a D channel are used for

access signaling, when appropriate, to select the B or

D channel for packet data transfer and for establishing

and releasing a physical path in the ISDN.

5. Refer to chapter 3 for the specification of methods for

providing OSI Network Services.

2.7.2 Implementation Agreements

This section gives Implementation Agreements for individual ISDNrelated protocols. The relevant protocol stacks are given in

figures 2.3 and 2.4.

2-8
December '89

OS I LAYER

3

Q.931

(1.451)

ISO 8208

(X.25 PLP)

Q.921 (1.441)

(LAPD)

1 D CHANNEL

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

ADDITIONAL SIGNALING

FOR INCOMING PACKET * CALLS

PACKET SWITCHED

SIGNALING AND INFORMATION

TRANSFER

* MAY BE NULL

Figure 2.3. Protocol Layers at S, T and U reference points

when D Channel is used in ISDN.

2-9
December '89

OS I LAYER

Q.931

(1.451)

ISO 8208

(X.25 PLP)

Q.921

(LAPD)

ISO 7776

(X.25 LAPB)

D CHANNEL B CHANNEL

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

and for Primary Rate ANS Tl. 403- 1989

I

1

1 I

1 SIGNALING FOR CIRCUIT

SWITCHED ACCESS*

ADDITIONAL SIGNALING

FOR INCOMING PACKET

CALLS*

* MAY BE NULL

igure 2.4. Protocol Layers at S, T and U reference points

. when B Channel is used in ISDN.

2 7 2 1 Physical Layer. Basic Access at "U"

ANS Tl. 601-1988, "Integrated Services Digital Network-Basic

Access Interface for Use on Metallic Loops for Application

on the Network Side of the NT-Layer 1 Specification"

applies

.

PACKET SWITCHED

SIGNALING AND INFORMATION

TRANSFER

2.7.2.2 Physical Layer. Basic Access at S and T

ANS Tl. 605-1989, "Integrated Services Digital Network- Bas ic

Access Interface at S and T Reference Points-Layer 1 Specifications" applies.

2.7.2.3 Physical Layer. Primary Rate at "U"

2-10
December '89

The physical layer is governed^ by ANS Tl. 403- 1989,

"Carrier-to-Customer Installation Metallic Interface," and

CCITT Recommendation 1.431-1988, "Primary Rate User-Network

Interface - Layer 1 Specification subject to the exceptions

given below.

The following portions of ANS Tl. 403. 1989 shall be

deleted.

- Section 5.3.1

- Section 5.6:

- Section 6.1:

- Section 6.3:

- Section 8.0:

- Section 8.3:

- Section 8.4.1:

- Section 9/

figure 9

- Table 2

- Table 3

The bit rate tolerance option of

+/- 200 bps.

The minimum pulse density of this

section.

The superframe format.

The complete section.

The reference to the SF format.

The text in paragraph 8.3.1.1 and

footnote 7(8.3.1.2).

Footnote 9

.

Provisions for the use of the RJ48M

connector

.

This table.

The illustration in table 3 of

"Robbed-Bit Signaling."

ANSI accredited subcommittee TlEl is developing a standard for

the ISDN primary rate interface at reference points "S" and

"T" as well as "U". One of the accepted guidelines for the

standard is consistency with ANS Tl. 403- 1989. It is intended

that, when this new ISDN-unique standard is adopted, this

agreement will be modified to reference it and will be

extended to cover interfaces at reference points "S" and "T" as well as "U" . The current standard mentioned is at the

default letter ballot level of the draft document: TlEl-2/89-

046R4, "ISDN Primary Rate Customer Installation Interfaces

Layer 1 Specification."

2-11
December '89

The following portions of ANS Tl. 403-1989 shall be

modified :

- Section 5.3.2 The text of this section is

replaced by:

"The line code is B8ZS except as noted in section 7," and

'•

' - Section 7.0: The reference to the pulse density

requirements of section 5.6 is

inappropriate. The text is

' '

: replaced by

' ' "The provisions of Clear Channel

Capability (CCC) depends upon the use of the B8ZS line code, though

the use of ZBTSI is one interim

method that may be employed by

agreement of the network and the

user"

The provisions of ANS Tl. 403-1989 shall be supplemented by

the provisions of CCITT Recommendation 1.431 - section 4.4.

2.7.2.4 Data Link Layer. D-Channel

CCITT Recommendation Q.921 (1.441), "ISDN User-Network

Interface Data Link Layer Specification" applies.

2.7.2.5 Signaling

CCITT Recommendations Q.931 (1.451), "ISDN User-Network

Interface Layer 3 Specification" applies.

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

.

1 On a Basic Rate Interface supporting the ISDN

virtual circuit service, all of Q.931 section 6 except for 6.1.1 and 6.2.1 (the sections covering

the circuit-switched access case) shall apply.

The following sections also apply: 2.2, packet

mode access connection states; 3.2, messages for

packet mode access connection control; 4-4.5,

section specifying general information element

2-12
December '89

handling and encoding; 4.7, information elements

for packet communications.

On a Primary Rate Interface supporting the ISDN

virtual circuit service all of Q.931 section 6 shall apply except for 6.1.1 and 6.2.1 (the

sections specifying the circuit switched access

case), 6.1.2.2, 6.2.2.2 and 6.4.2 (the sections

specifying D-Channel ISDN Virtual Circuit service

case). The following sections also apply: 2.2,

packet mode access connection states; 3.2

messages for packet mode access connection

control; 4-4.5, sections specifying general

information element handling and encoding; 4.7,

Information elements for packet communications.

On a Basic or Primary Rate Interface supporting

the unrestricted 64-Kbps circuit-mode service,

Q.931 sections 6.1.1, 6.2.1, 6.4.1 and 6.4.3

shall apply. The following sections also apply:

2.1, circuit mode connection states; 3.1, messages

for circuit mode connection control; 4-4.5,

sections specifying general information element

handling and encoding.

2.7.2.6 Data Link Layer B-Channel

The agreements on ISO 7776 specified in section 2.6.2 shall

apply here.

If the ISDN provides a circuit-mode service between two ISDN

packet-mode devices, then the layer 2 address shall be

assigned as follows:

For permanent ( "non- switched" ) circuit-mode

service, one terminal uses address A and the other

terminal uses address B, as arranged by prior

agreement , and

For demand ("switched") circuit-mode service, the

terminal originating the circuit-mode call uses address A and the other terminal uses address B.

2.7.2.7 Packet Layer

2-13
December '89

The agreements on ISO 8208 specified in section 2.6.3 shall

apply here. When ISO 8208 is used on the D-Channel, the

maximum DATA packet size (i.e., actually the maximum size of

the User Data Field in a DATA packet) shall be limited to

256 octets.

2 . 8 APPENDIX A

This appendix provides a cross-reference listing between those

sections of the CCITT ISDN Recommendations given in section 2.7 of

this document and the sections of the corresponding ANSI ISDN

Standards. This appendix does not supersede section 2.7 but merely

provides a pointer to those who wish to implement the ISDN procedures

based on ANSI Standards.

2.8.1 Data Link Layer. D-Channel

CCITT Recommendation Q.921, which is referenced in section

2.7.2.4 of this document, is identical to ANSI Standard Tl . 602

.

2.8.2 Signaling

The following table provides the cross-references between those

sections of CCITT Recommendation Q.931 referenced in section

2.7.2.5 of this document and the corresponding ANSI ISDN

Standards

.

2-14
December ' 89

Tabie 2.1. ANSI-CCITT Cross -References

CCITT RECOMMENDATION Q.931 ANSI Tl 608

Section 2

11 Section 4. 1 (refers to sec. 2.1.1 of ANSI Tl .607)

Section 2 2 Section 4. 2 Section 3 1 Section 5. 1 (refers to sec.

3 of ANSI Tl . 607)

Section 3 2 Section 5. 2 Section 4 1 Section 6. 1 Section 4 2 Section 6. 2 Section 4 3 Section 6. 3 Section 4 4 Section 6. 4

Section 4 5 Section 6. 5 Section 4 7 Section 6 . 5 Section 6 Section 7 Section 6 1 1 Section 7 . 1 1 Section 6 1 2 2 Section 7 . 1 2.2

Section 6 2 1 Section 7. 2 1 Section 6 2 2 2 Section 7 . 2 2.3

Section 6 4 1 Section 7 . 4 1 Section 6 4 2 Section 7 . 4 2 Section 6 4 3 Section 7. 4 3

2 9 Bibliography

Local Area Networks: Baseband Carrier Sense Multiple Access with

Collision Detection Access Method and Physical Layer Profiles and Link

Layer Protocol, FTPS 107, NTIS , U.S. Department of Commerce, 5285 Port

Royal Road, Springfield, VA 22161.

2-15

September 1990 Stable

NETWORK LAYER

Editor's Note: The term "Ongoing" used in this document refers to the

Working Implementation Agreements dated September 1990.

3.1 INTRODUCTION

This chapter presents agreements for providing the OSI network

service. Also contained here are agreements on network layer

addressing and routing.

3.2 SCOPE AND FIELD OF APPLICATION

These agreements cover both connectionless -mode and connection-mode

network services.

3.3 STATUS

This version of the agreements was completed in December 1989.

Additional material in 3.8 has been included since then. Part of this

material had been in 3.13 of the Working Document.

3.4 ERRATA

Editor's Note: This section may contain "Defect Report" and

resolutions material, and the versions of implementor

agreements to which this material aplplies.

The following defects are being progressed in ISO:

- ISO 9542, defects 1-12.

3.5 CONNECTIONLESS -MODE NETWORK SERVICE (CLNS)

3.5.1 ISO 8473

1. Subsets of the protocol:

o Implementations will not transmit PDUs encoded using

the inactive subset. Received PDUs encoded using the

inactive subset will be discarded.

o The non- segmenting subset will not be used.

Implementations will not generate data PDUs without a segmentation part. However, implementations will

3-1
September 1990 Stable

receive and correctly process PDUs which do not contain

the segmentation part.

2 . Mandatory Functions

o The lifetime parameter shall be used as specified in

Clause 6.4 of ISO 8473. The parameter shall have an

initial value of at least three times the network span

or three times the maximum transit delay (in units of

500 milliseconds), whichever is greater.

o The reassembly timer for an initial PDU at the

reassembly point shall be no greater than the largest

value of all lifetime parameters contained in all

derived PDUs.

o The use/non-use of checksums shall be capable of being

configured. The default setting shall be non-use.

o If the implementation supports the generation of an ER

PDU, the system shall insert in the destination address

field of the ER PDU the contents of the source

address field of the PDU that generated the error.

3. Optional Functions:

o The Security parameter is not defined by these

Agreements. Implementations shall not transmit the

parameter except where defined by bilateral

agreements

.

o Partial and complete source routing will not be

supported.^

o Partial record of route will be supported by

Intermediate systems.

o ISO 8473 will be followed with respect to QOS.

A defect exists with the Partial Source Routing option which

can cause PDUs to loop in the network until their lifetime

expires

.

3-2
June 1990 Stable

o For systems implementing the congestion notification

function, the following applies.

A Globally Unique QOS Maintenance parameter shall be

included in all PDU originated by End Systems. As

specified in ISO 8473, the initial value of the

Congestion Experienced flag (CE flag) within the

Globally Unique QOS Maintenance Parameter shall be set

by the originating End System to zero. All other flags

within the Globally Unique QOS Maintenance Parameter

shall be set based on the specific local needs of the

originating End System.

Intermediate systems not implementing queue length

averaging shall leave the CE flag in the same state as

it was received. In particular, no intermediate system

(IS) shall ever clear (set to zero) the CE flag.

.All intermediate systems shall monitor all incoming and

outgoing queues and compute average queue lengths as shown by example in table 3.1. The averaging is done

from the beginning of the previous cycle to the

current time. A cycle begins at the instant of the

first NSDU arrival after an idle period.

An IS should set the CE flag in all NSDUs forwarded on

a queue which has an average queue length greater than

one

.

The queue length averaging algorithm computes the

average queue length over two cycles, where the two

cycles are:

1) the "previous cycle," which is the interval

from when the IS becomes busy, until it

becomes idle and the idle ends (indicated by

the instant the first packet arrives to the

idle IS) , and

2) the "current cycle," which is the interval

from the end of the idle interval to the

current time instant when the average queue

length is computed.

An embodiment of the averaging algorithm is shown in

table 3.1.

3-3
June 1990 Stable

Table 3.1. Queue Length Averaging Algorithm

The algorithm makes use of the following variables:

t = Current time

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

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

Tq = time at the beginning of the previous cycle

T^ = time at the beginning of the current cycle

The algorithm consists of three components:

1. Queue Length Update: Beginning with qo = 0.

If the i^^ event is an arrival event, = qi-i+l

^• i . If the i^^ event is a departure event, q^ = qi-i-l

i 2 . Queue Area (integral) update:

. Area of the previous cycle = S qi-l (ti-t^.j^)

ti€{To,Ti)

Area of the current cycle = Z <li-l (^i-ti-i)

tic{Ti,t)

3 . Average Queue Length Update

: > .' Average Queue length over the two cycles

_ Area of the two cycles _ Area of the two cycles

Time of the two cycles t-TQ

o (Refer to the Ongoing Implementation Agreements

document for additional optional functions)

3.5.2 Provision of CLNS over Local Area Networks (LANS)

When providing CLNS over a LAN subnetwork, the following shall

apply:

1. The definition of CLNS shall be as specified in ISO

8348/Add. 1,

2. The protocol used to provide CLNS shall be ISO 8473

with agreements as specified in 3.5.1, and

1 - 3. The necessary subnetwork dependent convergence function

3-4
June 1990 Stable

shall be as defined in ISO 8473 - Clause 8.5.1, SNDCF

used with ISO 8802/2 sub-networks .

3.5.3 Provision of CLNS over X.25 Subnetworks

When providing CLNS over X,25 subnetworks, the following shall

apply:

1. The definition of CLNS shall be as specified in ISO

8348/Add. 1,

2. The protocol used to provide CLNS shall be ISO 8473

with agreements as specified in 3.5.1, and

3. The necessary subnetwork dependent convergence

function shall be as defined in ISO 8473 - Clause

8.5.2, "SNDCF used with ISO 8208 subnetworks for

operation over X.25 subnetworks," The default

throughput class shall be used if this facility is

available, and

4. The X.25 PLP shall be as specified in section 2.6.3.

3.5.4 Provision of CLNS over ISDN

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

3.5.4.1 CLNP Utilizing X.25 Services

o The definition of CLNS shall be as specified in ISO

8348/Add. 1,

o The protocol used to provide CLNS shall be ISO 8473

with agreements as specified in section 3.5.1, and

o The necessary Sub-network Dependent Convergence

function shall be as defined in:

ISO 8473 for operation of CLNP over X.25 with

agreements as specified in section 3.5.3, and

ISO 9574 for control of the B and D channels.

Note: The stated scope of ISO 9574 does not

explicitly cover the operation of CLNP

over an ISDN. However, the procedure

identified for operating X.25 in

3-5
June 1990 Stable

conjunction with 1.451 is still

applicable. The procedures in ISO 9574

that correspond to 8878 are not utilized

when providing CLNS

.

o The X.25 PLP shall be as specified in section 2.6.3.

o The agreements for the ISDN-related protocols are specified in section 2.7.

3.5.5 PROVISION OF CLNS OVER POINT-TO-POINT LINKS

(Refer to the Ongoing Implementation Agreements

document)

.

3.6 CONNECTION-MODE NETWORK SERVICE (CONS)

The following agreements concern provision of the connection-mode

Network Service.

3.6.1 Mandatory Method of Providing CONS

3.6.1.1 General

Independent of the subnetwork type (of sec. 2), when

providing the CONS using X. 25-1984, the following shall

apply as described below.

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 Packet Layer Protocol (PLP) is as specified

in section 3.6.3.1.

o The general procedures and formats of the X.25 PLP are

as specified in ISO 8208, X.25 Packet Layer Protocol

for Data Terminal Equipment .

3.6.1.2 X.25 WAN

No provisions additional to those in section 3.6.1.1 apply

in an X.25 WAN.

3-6
June 1990 Stable

3.6.1.3 LANs

When providing the CONS in a Local Area Network, the

following aspects of ISO 8881, in addition to the documents

listed in section 3.6.1.1, shall apply:

o Clauses 1-6 and 9-11 for LLC Type 1 operation,

including the additional nonstandard default packet

size listed in Clause 6.3, Note 2

Note: Operation of ISO 8208 in conjunction with LLC

Type 2 requires agreement on LLC Type 2

procedures

.

3.6.1.4 ISDN

When providing the CONS in an ISDN, the considerations for

control of a B and D channel in ISO 9574, in addition to

those provided in section 3.6.1.1, shall apply.

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

Subnetworks

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

shall apply:

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

Network Service Definition , and

o The subnetwork dependent convergence protocol

required to provide CONS shall be as specified in ISO

8878 Annex A, and referred to as the Alternative

Procedures for Network Connection Establishment and

Release . with agreements as defined in 3.6.3.2.

3.6.3 Agreements on Protocols

3.6.3.1 ISO 8878

ISO 8878 Clauses 1-11 shall apply with the following

exception:

o Where the ISO 8208 diagnostic codes are not provided,

all Cause/Diagnostic code combinations can be mapped

to the Originator/Reason code of "Undefined."

3.6.3.2 Subnetwork Dependent Convergence Protocol (ISO

8878/Annex A)

3-7
June 1990 Stable

o The Receipt Confirmation service will not be provided,

so the corresponding protocol elements need not be

implemented

.

o The Expedited Data service will not be provided,

so the corresponding protocol elements need not be

implemented.

3.6.4 Interworking

. Interworking between subnetworks whose End Systems use ISO 8208

to provide the CONS as specified in section 3.6.1 shall be

performed as specified in ISO TR 10029. That is, an Intermediate

System connecting two such subnetworks shall operate ISO 8208 on both subnetworks and shall relay information from one subnetwork

to the other as described in ISO TR 10029.

3.7 ADDRESSING

NSAP address formats supported will conform to Addendum 2 of ISO

8348.

o NSAP address formats will have a hierarchical structure.

This will reduce the size of routing tables.

o If used in the Domain Specific Part (DSP) , an NSAP selector

shall be the least significant component in the hierarchy,

and shall be encoded as the last octet of the DSP. The NSAP

selector shall not be used to perform routing; it is simply

intended to identify the network service user at the

destination end system. For those implementations using an NSAP selector, there shall be one and only one selector

for each NSAP within the end system. All NSAP addresses

identifying a given NSAP will use the same NSAP selector

value

.

3.8 ROUTING

The basic principles of Network Layer routing are defined in the OSI

Routing Framework ISO TR 9575. These principles include:

- The global OSI environment will consist of a number of

Administrative Domains. An Administrative Domain consists of a collection of End Systems (ES) and Intermediate Systems (ISs)

,

and subnetworks operated by a single organization or Administrative Authority. The Administrative Authority is

responsible for: the organization of ESs and ISs into Routing

Domains; the assignments of NSAP and SNPA addresses; the policies

3-8
June 1990 Stable

that govern resource usage; the policies that govern the

information that is collected and disseminated both internally

and externally to the Administrative Domain; and, the

establishment of subdomains and the corresponding delegation of

responsibilities

.

A Routing Domain is a set of ESs and ISs which operate according

to the same routing procedures and which is wholly contained

within a single Administrative Domain. An Administrative

Authority may delegate to the entity responsible for a Routing

Domain the responsibilities to further structure and assign NSAP

and SNPA addresses. The hierarchical decomposition of Routing

Domains into subdomains may greatly reduce the resources required

in the maintenance, computation, and storage of routing

information.

The OSI routing problem, and consequently OSI routing protocols,

has been decomposed into three distinct classes:

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

IS to IS routing within a single routing domain (Intradomain)

.

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

.

The -GSI -routing -problem -has -been -decomposed -into -two -distinct -classes

of -routingt

End -Systems -fES> -to -Intermediate -Systems -6IS> -routtngT

IS-to-IS -routingT

3.8.1 End System to Intermediate System Routing

For use in conjunction with ISO 8473 over LANs (refer to sec. 2.5) and point-to-point links, ISO 9542 shall be used to

provide the routing exchange protocol.

Additionally, a management mechanism capable of adding and

deleting entries into the Routing Information Base (RIB) is

recommended. When using the management mechanism to add an

entry, there should be no holding timer, and the entry should be

write protected from alteration by the ES-IS protocol. This

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

The agreements below apply to the use of ISO 9542.

3-9
June 1990 Stable

1. Implementors shall support any valid NSAP format. For

the purposes of the protocol, NSAP addresses are treated simply as octet strings.

2. For LANs, implementors shall support both

Configuration Information and Route Redirection

Information; no subsets are permitted.

3. All timer values shall be configurable.

4. Use or non-use of checksums shall be configurable. It

is recommended not to use ISO 9542 checksums when

originating PDUs.

5. The QOS , Security and Priority parameters should not be

used for routing. For conformance, intermediate

systems must transmit these parameters in RD PDUs if

they are present in the data PDU which generated the

redirect. However, end systems must ignore them in

received RD PDUs.

6. If the configuration notification function described

in clause 6.7 of the protocol specification is

implemented, a mechanism shall be provided to

enable/disable this function on broadcast networks. If

supported in end systems listening to both ISHs and

ESHs , this function shall only be invoked upon receipt

of an ISH.

An alternative mechanism for achieving rapid

configuration which is scaleable to large broadcast

networks is described below. This mechanism makes use

of the Suggested ES Configuration Timer.

Implementation of this mechanism is optional.

IS Actions

a) IS Actions

When an Intermediate system wants to quickly acquire

the End system configuration (for example, when a broadcast circuit is enabled on the IS or the topology

changes because of a failure of a bridge or repeater)

,

it initiates a "poll" of the End system configuration

by performing the following actions:

1. Delay a random interval between 0 and

PollESHelloRate seconds. (This is to avoid

3-10
June 1990 Stable

synchronization with other ISs which have detected

a change .

)

2. In order to rapidly time out any End systems which

are no longer present on the broadcast circuit

(for example, after a LAN partition), reset the

entryRemainingTime in the Routing Information Base

for all End systems on this circuit to the value:

(ISHelloTimer + PollESHelloRate) * HoldingMultiplier

or the existing value whichever is lowest. Where

ISHelloTimer is the Intermediate system's configuration

timer, HoldingMultiplier is a predefined number (for

example, 2) which multiplied by ISHelloTimer gives the

value for the Holding Time field of IS Helios.

3.. Then transmit HoldingMultiplier IS Helios with a Suggested ES Configuration Timer value of

PollESHelloRate seconds with an interval of

ISHelloTimer seconds between each and setting the

Holding Time field to ISHelloTimer * HoldingMultiplier.

4. Then start sending IS Helios with a Suggested ES

Configuration Timer of DefaultESHelloRate seconds

(where DefaultESHelloRate is larger than

PollESHelloRate)

.

b) ES Actions

An End system maintains for each circuit a list

(CTList) which has HoldingMultiplier elements each of

which stores a received value of the Suggested ES

Configuration Timer. The function SaveCT(t) adds the

value t as the first element of CTList and discards the

last element. The function MinCT delivers the minimum

value in CTList. When the circuit is enabled all the

elements of CTList are initialized to PollESHelloRate.

An End system also maintains for each circuit the

variables currentSuggestedHelloTimer and its associated

lifetime currentSuggestedHelloTimerLifetime . These are both initialized to PollESHelloRate.

When the circuit is enabled the Configuration Timer is

started by setting the entryRemainingTime to random

(PollESHelloRate)

.

3-11
June 1990 Stable

On Configuration Timer expiry the following actions are performed:

1. SaveCT(currentSuggestedHelloTimer)

.

2. Transmit an ES Hello with Holding Time field set

to MinCT * HoldingMultiplier

.

3. Set entryRemainingTime to MinCT - random(MinCT * 0.25). (The random element ensures that End

systems do not become synchronized.)

When an End system receives an IS Hello which contains

a Suggested ES Configuration Timer, it is processed as follows (where suggestedESCT is the value contained in

the option)

1. If suggestedESCT is less than or equal to

currentSuggestedHelloTimer then set

curentSuggestedHelloTimerLifetime to the value of

the Holding Time field of the IS Hello.

2. If suggestedESCT is less than

currentSuggestedHelloTimer then set

currentSuggestedHelloTimer to suggestedESCT and

reset entryRemainingTime to the smaller of its

current value and

random(currentSuggestedHelloTimer * 0.75).

When the currentSuggestedHelloTimerLifetime expires,

set the currentSuggestedHelloTimer to

DefaultESHelloTimer.

For LANs, this protocol employs the same LSAP as ISO

8473.

The encoding of the BSNPA address follows the syntax

rules for the data link being used. On a LAN, for

example, it is a 48-bit MAC address.

The multicast addresses corresponding to "all

intermediate systems on the network" (ALL_ISN) and "All

End Systems on the Network" (ALL_ESN) shall default to

the following on IEEE802.3 and IEEE802.4 subnetworks:

ALL_ESN = 0900 2B00 0004

ALL ISN = 0900 2B00 0005

3-12
June 1990 Stable

It is understood that the hexadecimal octets shown are transmitted onto the medium form left most octet to

right most octet. Within each hexadecimal octet the

least significant bit is transmitted first.

10. The multicast addresses corresponding to "All

Intermediate Systems on the network" (ALL ISN) and "All

End systems on the Network" (ALL_ESN) shall default to

the following two functional addresses on IEEE802.5

subnetworks

ALL_ESN = COOO 0000 4000

ALL_ISN - COOO 0000 8000

It is understood that the hexadecimal octets shown are transmitted onto the medium from left most octet to

right most octet. Within each hexadecimal octet the

most significant bit is transmitted first."

9t For -LANs ,- -the -muttieast -addresses -corresponding -to -'^AH

Intermediate -Systems -on -the -network'^ -(^Al:l:_;ISN)- -and -'^AH

End -Systems -on -the -network'^ -(A]:1:^ESN> -shall -default -to

the -foHowingf

AH^ESN -=- -0900 -2BGG -0004

AH^ISN -=- -0900 -2BG0 -0005

Note i Version - 1 7 - Edition- 4- -of- -the&e- -agreements -had

the - above- -addr-esses- - reversed- -<4-.e-.-,- -Alt^ISN was -given -as -0900 -2B00 -0004 ,- -etc .-> -because -of an - - unintentional er-r-or^ - - in- - <:he original

proposal .- There - -is- - no- -intent - -to- -maintain

compatibility - with- -sys-t-ems- - using- -Ver-sion- - ty

Edition -1 -addressesv

For -IEEE -802 .-3 -and -802 .-4 -LANs ,- -it -is -understood -that

the -hexadecimal -octets -shown -are -transmitted -onto -the

medium -from -left-most -octet -to -right-most -octet .-- Within -each -hexadecimal -octet ,- -the -least -significant

bit -is -transmitted -first

7

11. The Error Report flag shall be set to zero (0) for

NPDUs sent as a result of invoking the QUERY

Configuration Function.

2 Intermediate Systems to Intermediate Systems Routing

3-13
June 1990 Stable

Intermediate systems shall provide mechanisms to create and

update the required Routing Information Base.

PROCEDURES FOR OS I NETWORK SERVICE/PROTOCOL IDENTIFICATION

3.9.1 General

The Protocol Identifiers specified in ISO DTR 9577 ("Protocol

Identification in the OSI Network Layer") provide a basis from

which OSI systems (both end systems and intermediate systems) may

derive a set of procedures for indicating which OSI protocols are used in a particular instance of communication. As such, these

procedures are only concerned with Initial Protocol Identifiers

(IPIs) and Subsequent Protocol Identifiers (SPIs) that identify

OSI protocols and pertain to the following types of systems:

A. systems providing/supporting only CONS (using ISO

8208/8878)

,

: B. systems providing/supporting only CLNS (using ISO

8473), and

C. systems providing/supporting both CONS and CLNS.

From this set of definitions, the following possibilities for

success (S) or failure (F) of an instance of communication can be

defined, as shown in the table below:

Table 3.2. End Systems Communications

Originating Destination End System Type

End System Type A B c

A S F S

B F S s C S S S

3.9.2 Processing of Protocol Identifiers

The usage of Protocol Identifiers in Network Protocol Data Units

(NPDUs) depends on several factors:

the OSI Network Service to be provided,

3-14
June 1990 Stable

the protocol to be used in providing this service,

the role the protocol is to be used in (per the Internal

Organization of the Network Layer)

,

and

the type of subnetwork to which the system is connected.

3.9.2.1 Originating NPDUs

The use of a particular OSI Network Service depends on the

capabilities of both the origination and destination end

systems. It is not the intent of this section to provide

guidelines on how to make this choice except for simple

obvious criteria; rather, it is intended only to provide

guidance on how to convey this choice to the destination

system.

Where a priori knowledge exists in the originating end

system about the capabilities (with respect to OSI Network

Services available) of the destination end system, it should

be used. This may result in no communication if the two end

systems involved only provide Network Services of different

types. A selection is required in cases where both end

systems provide both types of network services; this

selection is conveyed by the use of the IPI and SPI (but the

selection process is an implementation matter)

.

Alternatively, where a priori knowledge does not exist,

then the selection of a service to use in an instance of

communication depends solely on the capabilities of the

originating end system as described below.

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

Identifiers specified so as to reflect the chosen

protocol(s) and service.

If only CLNS-related protocols (e.g., 8473) are available, then this should be used and the Protocol

Identifiers specified so as to reflect the chosen

protocol(s) and service.

If both services are available, then other criteria are used in deciding which to use in an instance of

communication.

Note: The choice of OSI Network Service to be used in an instance of communication is reflected in the

Network Service primitives issued by the Network

Service user.

3-15
June 1990 Stable

Once a selection of Network Service has been made, the use

of particular protocols depend on, for example, the

subnetwork to which the originating End System is attached.

Some specific cases are given in Annex A of ISO DTR 9577.

Another case involves use of the Protocol for Providing the

Connectionless Network Service directly over the Data Link

Service, as given in ISO 8473 (e.g., in a LAN). In this

case, the IPI indicates ISO 8473.

3.9.2.2 Destination System Processing

A system receiving an NPDU must first be concerned with the

protocol identified by the IPI. Valid values are given in

table 2 of ISO DTR 9577. If the protocol is recognized as one supported by the system, further processing of the

protocol is performed according to the rules of that

protocol. If not, an error is recognized and may be

conveyed to the originating peer entity. With respect to

ISO 8208 and ISO 8473, the following would apply for such

error conditions.

1. For ISO 8208, the condition is classified as an "invalid General Format Identifier," for which a DIAGNOSTIC packet may be returned. If DIAGNOSTIC

packets are not used by the system, the NPDU is

discarded without any further action.

2. For ISO 8473, the NPDU is discarded without any

further action.

Given acceptance of the protocol identified by the IPI, the

system must also determine the acceptability of the

subsequent protocols and OSI Network Service being

requested. Use of ISO 8473 implies CLNS ; however, use of

ISO 8208 can imply either CONS or CLNS, as identified by the

SPI . In the case of ISO 8208, therefore, further processing

is needed to determine the acceptability of the requested

protocol/service. If these are not acceptable (e.g., not

supported by the system) , the call should be cleared with a diagnostic code of "Connection Rejection - unrecognizable

protocol identifier in user data" (decimal 249)

.

Note: In ISO 8208, a call may be refused for

reasons other than non- support of the

requested OSI Network Service.

3-16
June 1990 Stable

3.9.2.3 Further Processing in Originating End System

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

determine the success of such an attempt.

For ISO 8473, when used directly over the Data Link Service,

the success or failure of an attempt to communicate may not

be visible/obvious within the Network Layer. On the other

hand, use of ISO 8473 over ISO 8208 may provide, via the

diagnostic code in a received CLEAR INDICATION packet, an indication of failure to communicate (e.g., the remote

system does not support CLNS).

When using ISO 8208 to provide the CONS, the diagnostic code

in a received CLEAR INDICATION packet may provide the

necessary indication of why a call was refused. In cases where an ISO 8208 call is refused with diagnostic #249, it

would not be desirable to re-attempt such calls with the

exact same set of parsimeters ; however, how the originating

system ensures this is a local matter.

In cases where an originating system is capable of

supporting both OSI Network Services, it may wish to re- attempt communications using the other mode of Network

Service than that initially attempted.

3.9.3 APPLICABLE PROTOCOL IDENTIFIERS

The protocol identifiers applicable to these agreements are given

in table 3.1 and table 3.2.

Table 3.1. IPI Values

Bit Pattern 87654321 Protocol

00001000

1 0 0 0 0 0 0 1 10000010

X X 0 1 X X X

xxl Oxxxx

OOllxxxx

CCITT I.451/Q.931

ISO 8473 (excluding the

inactive subset)

ISO 9542

ISO 8208/CCITT X.25-Modulo 8

ISO 8208/CCITT X.25-Modulo 128

ISO 8208/CCITT X.25-GFI Extension

3-17
June 1990 Stable

Table 3.2. SPI Values

Bit Pattern *

8 7 6 5 4 3 2 1 Protocol

00000000

thru

0 0 1 1 1 1 1 i 10000001

10000100

" ' ' - ISO 8073 ADDl/CCITT X.224

See table 4.1

ISO 8473

ISO 8878/Annex A

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

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

shall indicate ISO 8073/CCITT X.224.

When using ISO 8208, values other than one of those listed in

table 3.2 are outside the scope of these agreements.

3.10 MIGRATION CONSIDERATIONS

This section considers problems arising from evolving OSI standards

and implementations based on earlier versions of OSI standards.

3.10.1 X. 25-1980

Until there is widespread availability of 1984 X.25 service, it

will be necessary for X.400 systems to use those existing packetswitched public data networks which offer only pre- 1984 X.25

service. While 1980 X.25 does not provide the CONS as defined by

ISO 8348, there is no implication of non- conformance to these

Agreements resulting there from for systems using 1980 X.25 to

interchange data at the Network Layer, provided they conform in

all other respects.

This is an exception to the Agreements for providing the OSI

Network Service, granted temporarily for practical reasons. This

exception will be removed when it is deemed to be no longer

necessary, in the judgement of the Workshop. While this

provision is in effect, it provides an alternative method of

using 1980 X.25 to the provisions of 3.6.2.

3-18
June 1990 Stable

3.11 USE OF PRIORITY

(Refer to the Ongoing Implementation Agreements document)

.

3.11.1 INTRODUCTION

(Refer to the Ongoing Implementation Agreements

document)

.

3.11.2 OVERVIEW

(Refer to the Ongoing Implementation Agreements

document)

.

3.12 CONFORMANCE

(Refer to the Ongoing Implementation Agreements document)

,

3. 13 BIBLIOGRAPHY

1. CCITT Recommendation X.223 - 1988, Use of X.25 to Provide the OSI

Connection-mode Network Service for CCITT Applications.

2. Interface Between Data Terminal Equipment (DTE) and Data CircuitTerminating Equipment (DCE) for Operation with Packet-Switched

Data Communications Networks, FIPS 100, NTIS, U.S. Department of

Commerce, 5285 Port Royal Road, Springfield, VA 22161.

3. Information Processing Systems - Data Communications - Protocol

Combinations to Provide and Support the OSI Network Service - Part 1: General Principles, ISO/IEC 8880-1.

4. Information Processing Systems - Data Communications - Protocol

Combinations to Provide and Support the OSI Network Service - Part 2: Provision and Support of the Connection-mode Network

Service; ISO/IEC 8880-2.

5. Information Processing Systems - Data Communications - Protocol

Combinations to Provide and Support the OSI Network Service - Part 3: Provision and Support of the Connectionless -mode Network

Service; ISO/IEC 8880-3.

6. Information Technology - Telecommunications and Information

Exchange Between Systems - OSI Routing Framework; ISO/IEC TR

9575.

3-19
I

it
September 1990 (Stable)

4^ TRANSPORT

Editor's Note: The term "Ongoing" used in this section refers to the

Working Implementation Agreements document dated

I September 1990.

4.1 INTRODUCTION

These agreements support the integration of LANs, packet networks, and

other WANs with the smallest possible set of mandatory protocol sets,

in accordance with the other agreements already reached. Nothing here

shall preclude vendors from implementing protocol suites in addition

to the ones described in this document.

4.2 SCOPE AND FIELD OF APPLICATION

This chapter presents agreements for providing the OSI Transport

layer services over both connection mode and connection- less mode

services

.

4.3 STATUS

Completed December 1989.

4.4 ERRATA

4.5 PROVISION OF CONNECTION MODE TRANSPORT SERVICE

Three connection mode protocol classes have been identified for

implementation. Transport classes 0, 2 and 4 of X.224 (1988)^ have

been endorsed for use over CONS. Only Transport Class 4 of ISO

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

combinations are endorsed for CONS: (0), (0,2) or (0,2,4).

^ Where a CR TPDU proposing Class 2 or 4 is initiated. Class 0

shall be explicitly indicated as an alternative class except if

there is already one (or several) transport connection(s)

assigned to the network connection (multiplexing being possible)

.

2 In general, references to ISO 8073 in ISO 8073/Add. 2 should be

interpreted as applying to X.224 (1988); however, the reference

to Clause 14. 6. a in Clause 14 of ISO 8073/Add. 2 should be

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

4-1
1 TRANSPORT CLASS 4

September 1990 (Stable)

4.5.1.1 Transport Class 4 Overvlev

Transport Class 4 is mandatory for communication between

systems using the OSI CLNS and may also be used for systems

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

4.5.1.2 Protocol Agreements

A disconnect request shall be issued in response to a connect request when the maximum number of Transport

connections is reached or exceeded.

4.5.1.2.1 General Rules

o All implementations shall request "use of

extended formats" in the CR TPDU. Implementations

shall accept the "use of extended formats" in the

CC TPDU if it was proposed in the CR TPDU.

Implementations shall accept "use of normal

formats" if it was proposed in the CR TPDU.

o Negotiation of protection is outside the scope of

these agreements. If negotiation of protection

is not supported, receipt of the protection

parameters in CR TPDU and CC TPDU shall be

ignored.

o Implementations shall be capable of proposing and

accepting the non-use of checksums.

o Use of the acknowledgment time parameter is

optional. If an implementation is operating any

policy which delays the transmission of AK TPDUs

,

the maximum amount of time by which a single AK

TPDU may be delayed shall be indicated to the peer

Transport service provider using the

acknowledgment time parameter. The value

transmitted should be expressed in units of

milliseconds and rounded up to the nearest whole

millisecond.

o QoS negotiation is outside the scope of these

agreements. If QoS negotiation is not supported,

receipt of the parameters "throughput," "residual

4-2
December '89

error rate," "priority," and "transit delay" in

the CR and CC TPDUs shall be ignored.

o It is recommended that implementations not send

user data in the CR TPDU or the CC TPDU. The

disposition of any user data received in a CR TPDU

or CC TPDU is implementation dependent.

o It is recommended that implementations not send

user data in the DR TPDU. The disposition of any user data received in a DR TPDU is implementation

dependent

.

o An unknown parameter in any received CR TPDU shall

be ignored.

o A Transport entity shall accept a DR TPDU and a corresponding DC TPDU with or without a checksum

in response to a CR or CC TPDU.

o Transmitted DR TPDUs shall carry a disconnect

reason code which pertains to the actual cause of

the disconnect. A DR TPDU may carry a reason code

of "0" (unspecified) if an appropriate reason

code is not defined.

o Known parameters with valid lengths but with

invalid values in a CR TPDU shall be handled as follows

Parameter

TSAP id

TPDU size

Version

Checksum

Alternate Protocol

Classes

Action

Send DR TPDU

ignore parameter,

ignore parameter,

discard CR TPDU

Protocol Error

use default

use default

o Unrecognized or not applicable bits of the

Additional Options parameter shall be ignored.

4.5.1.2.2 TRANSPORT CLASS 4 SERVICE ACCESS POINTS OR

SELECTORS

If present, the TSAP Id. field in the CR and CC TPDUs

shall be encoded as a variable length field and will be

interpreted as an octet string. The length of the

string cannot exceed 32 octets.

4-3
December ' 89

4.5.1.2.3 Retransmission Timer

It is recommended that the value used for the

retransmission timer be based upon the round- trip delay

experienced on a transport connection. The

implementation should maintain, and continually update, an estimate of the round- trip delay for the TC. From

this estimate, a value for the retransmission timer is

calculated each time it is started. An example

technique for maintaining the estimate and calculating

the retransmission timer is described below. The

value of the retransmission timer may be calculated

according to the following formula:

Tl < kE + AR

In this formula, E is the current estimate of the

round- trip delay on the transport connection, AR is

the value of the acknowledgement time parameter

received from the remote transport service provider

during connection establishment, and k is some locally

administered factor.

A value for k should be chosen to keep the

retransmission timer sufficiently small such that lost

TPDUs v;ill be detected quickly, but not so small that

false alarms are generated causing unnecessary

retransmission

.

The value of E may be calculated using an exponentially

weighted average based upon regular sampling of the

interval between transmitting a TPDU and receiving the

corresponding acknowledgment. Samples are taken by

recording the time of day when a TPDU requiring

acknowledgment is transmitted and calculating the

difference between this and the time of day when the

corresponding acknowledgment is received. New samples

are incorporated with the existing average according to

the following formula.

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

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

1. The value chosen for a determines the relative

weighting placed upon the current estimate and the new

sample. A large value of a weights the old estimate

more heavily causing it to respond only slowly to

variations in the round- trip delay.

4-4
December '89

A small value weights the new sample more heavily

causing a quick response to variations. (Note that

setting Q to 1 will effectively disable the algorithm

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

initial seed.)

If a is set to 1-2"^ for some value of n, the update

can be reduced to a subtract and shift as shown below.

E < E + 2'" (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

by the most recently transmitted DT TPDU. This

attempts to minimize in the sample any delay caused by

the remote transport service provider withholding AK

TPDUs

.

4.5.1.2.4 Keep-Alive Function

The Class 4 protocol detects a failed Transport

connection by use of an 'inactivity timer'. This timer

is reset each time a TPDU is received on a connection.

If the timer ever expires, the connection is

terminated

.

The Class 4 protocol maintains an idle connection by

periodically transmitting an AK TPDU upon expiration of

the 'window timer'. Thus, in a simple implementation,

the interval of one transport entity's window timer

must be less than that of its peer's inactivity timer,

and vice versa. The following agreements permit

communicating transport entities to maintain an idle

connection without shared information about timer

values

.

o In accordance with ISO 8073/X.224, Clause

12. 2. 3. 9. a, all implementations must respond to

the receipt of a duplicate AK TPDU not containing

FCC by transmitting an AK TPDU containing the

'flow control confirmation' parameter.

4-5
December '89

o Implementations must always transmit duplicate AK

TPDUs without FCC on expiration of the local

window timer (see ISO 8073/X.224, Clause

12.2.3.8.1). Receipt of this TPDU by the remote

Transport entity will cause it to respond with an AK TPDU containing the 'flow control confirmation'

parameter. When this is received by the local

transport entity, it will reset its inactivity

timer. See figure 4.1.

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

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.

A duplicate AK TPDU (See fig. 4.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.

4-6
December '89

W

reset

reset

expire

expire

duplicate

AK

AK + FCC

duplicate

AK

AK + FCC

expire

Figure 4.1. AK exchange on idleconnection.

4.5.1.2.5 Congestion Avoidance Policies

This section defines both mandatory and optional

requirements relating to avoiding congestion in OSI

networks and recovering from it when it is

experienced. The mandatory requirements specify a minimum approach to congestion avoidance/recovery

which can be tuned based upon the specific

requirements of the network. The optional

requirements specify a dynamic window sizing scheme

which, if implemented, will contribute further to the

avoidance of congestion in the network.

Mandatory Requirements

1 A maximum size for the "receive credit window,"

the value of which is locally configurable, should

be provided. A "receive credit window" reflects

the number of credits sent by a Transport entity

for a Transport connection. The maximum size of

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

4-7
December '89

2 A maxiimam size for the "sending credit window,"

the value of which is locally configurable, shall

be provided. A "sending credit window" reflects

the number of data TPDUs that a Transport entity

is willing to send on a Transport connection. The

maximum size of the "sending credit window" shall

be referred to as WS^. As specified in ISO 8073,

the "sending credit window" shall also be less

than or equal to the remote "receive credit

window" as conveyed in the last CDT field.

3 It is strongly recommended that an implementation

use a retransmission timer per Transport

connection. If, upon expiration of the

retransmission timer, an implementation allows

more than "1" TPDU to be transmitted a means to

locally adjust the maximum number shall be

provided.

4 All implementations shall have the capability of

operating without delaying ACKs of data TDPUs

received in-sequence (i.e., Al essentially equals

zero) . If an implementation optionally chooses to

explicitly delay ACKs, a means to locally adjust

Al shall be provided.

Optional Requirements

For systems implementing the dynamic window sizing

scheme the following rules apply as described below.

RECEIVING TRANSPORT ENTITY (RTE) RXJLES:

Rule 1: Initialization of Window

The initial value of WR (known as WRq) shall

have a locally configurable upper bound.

This window is sent to the sending transport

entity (STE) in the next CDT field

transmitted.

Rule 2: Required Sampling Period

All RTEs shall maintain a fixed value for WR

until the next 2WR DT TPDU arrive since the

last CDT field was transmitted by the RTE.

Rule 3: Required Counting of Received TPDUs in a Sampling Period

4-8
December '89

All RTEs shall maintain a count, N equal to

the total number of TPDUs received and a count, NC equal to the total number of TPDUs

received which had the CE Flag set. All

types of TPDUs are included in the counts for

N and NC, not just DT TPDUs.

Rule 4: Required Action upon the end of a Sampling

Period

All RTEs shall take the following action at

the end of each sampling period:

o If the count NC is less than 50

percent of the count N, the RTE

shall increase WR by adding 1 up to a maximum, WR^ , (that is based on

the local buffer management policy)

otherwise, it shall decrease WR by

multiplying by 0.875 (a minimum of

1).

o Reset N and NC to zero.

o Transmit the new window WR in the

next CDT field sent to the sending

transport entity.

SENDING TRANSPORT ENTITY (STE) RULES

Rule 1: Initialization of Window

All STEs shall maintain a sending window size

(WS) . Initially and also as long as there is no loss, WS is set equal to the receiving

window value WR received from the remote RTE

in the last CDT field.

Rule 2: Required Action on a Timeout

All STEs shall reset WS to one when the

retransmissions timer expires and indicates a lost TPDU. WS now limits the number of DT

TPDUs that may be transmitted or retransmitted without further

acknowledgments

.

Rule 3: Required Counting of Acknowledged TPDU

4-9
December ' 89

All STEs shall maintain a count , ACKRCVD of

the number of DT TPDUs acknowledged, by the

RTE , since WS was last adjusted. Therefore

each time WS is adjusted, the count ACKRCVD

shall be reset to zero.

Rule 4: Increase Window Policy

All STEs shall increase WS by one each time

ACKRCVD is equal to or greater than the

current value of WS , unless WS exceeds the

window permitted by the remote RTE.

4.5.1.2.6 USE OF PRIORITY

(Refer to the Ongoing Implementation Agreements)

.

Transport Class 0

4-10
December '89

4.5.2.1 Transport Class 0 Overview

Transport Class 0 over X.25 is mandatory (see X.400) for use

in communicating with public MHS systems operating in

accordance with the CCITT X.400 series recommendations. The

purpose of the agreements concerning Transport Class 0 is to

allow connection to these public services. Transport Class

0 over X.25 can also be used in communicating between PRMDs

(this choice is prevalent outside North America).

4.5.2.2 Protocol Agreements

Transport Class 0 agreements follow.

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.

o The allowed values for the maximum TPDU size are 128,

256, 512, 1024, and 2048.

o The Class 0 protocol does not support multiplexing. At

any instant, one Transport corresponds to one Network

connection.

o It is recommended that the optional timers TSl and TS2

,

if implemented, be settable by local system management.

Values in the order of minutes should be supported.

o An unlimited TSDU length must be supported.

4.5.2.2.1 Transport Class 0 Service Access Points

For communicating with public MHS systems, section 5 of

X.410 specifies the use and format of TSAP identifiers.

4.5.2.3 Rules for Negotiation

The rules for class negotiation shall be used.

4-11
December '89

4.5.3 Transport Class 2

4.5.3.1 Transport Class 2 Overview

Transport Class 2 is applicable in OSI end systems which

provide the Connection-mode Network Service.

4.5.3.2 Protocol Agreements

Transport Class 2 agreements follow:

The values of the TSl and TS2 timers shall be

configurable. The recommended timer values are:

TSl : 60 seconds

TS2 : 60 seconds

If present, the TSAP-id field in the CR and CC TDPUs

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

The rules for class negotiation shall be used.

QoS negotiation is outside the scope of these

agreements. If QoS negotiation is not supported,

receipt of the parameters "throughput," "residual error

rate," "priority," and "transit delay" in the CR and

CC TPDU shall be ignored.

Note 1: If Class 0 is indicated in the Alternative

Protocol Class field and QoS parameters are conveyed and the responding end system

chooses Class 0, then the QoS parameters have

been ignored by the responding system.

4.6 PROVISION OF CONNECTIONLESS TRANSPORT SERVICE

Document ISO 8072/Add. 2 is the Transport Service Definition

covering Connectionless-mode Transmission. Document ISO 8602 is the

Protocol for providing the Connectionless -Mode Transport Service.

4-12
December '89

4.6.1 Connectionless Transport Overview

When providing the connectionless Transport Service, the

protocol shall be implemented as specified in ISO 8602.

4.6.2 Protocol Agreements

The connectionless Transport protocol is a relatively simple

protocol providing little opportunity for conflicting

interpretations. A few relevant agreements follow.

o The optional elements of procedure for use of CLTS over

CONS (i.e., clause 6.3 of ISO 8602) will not be

supported.

o A Unitdata TPDU that is received that contains a protocol error or an unknown destination TSAP ID shall

be discarded.

4 6 2 1 Connectionless Transport Service Access Points or Selectors

The TSAP selector field in the UD TPDU shall be encoded as a variable length field and will be interpreted as an octet

string. The length of the string cannot exceed 32 octets.

4.7 TRANSPORT PROTOCOL IDENTIFICATION

The absence of Call User Data (CUD) in an X.25/ISO 8208 Call

Request/Incoming Call packet indicates the operation of ISO

8073/CCITT X.224.

Protocol Identification TPDU values applicable to these agreements are given in table 4.1. These TPDUs , when used, are conveyed as N-connect

user data.

4-13
December '89

Table 4.1. Protocol Identification TPDU Values

TPDU Value Protocol

03 01 01 00 *

03 01 02 00

ISO 8073/Add. 1

ISO 8602

Notes: * Corresponds to an ISO 8073/Add. 1 UN-TPDU

and a X.224 Annex B PI -TPDU.

Corresponds to an ISO 8073/Add. 1 UN-TPDU

The following agreements apply.

o Any additional TPDU, which follows (by concatenation) a Protocol Identification TPDU shall be ignored if ISO

8073/Add. 1 is not supported.

o When using ISO 8208, usage of a Protocol Identification TPDU

not corresponding to those listed in table 4.1 is outside

the scope of these agreements

.

4-14
March 1990 (Stable)

5^ UPPER LAYERS

5.1 INTRODUCTION

In this portion of the Implementors ' Agreements, the NIST Upper Layers

SIG is primarily concerned with providing implementation agreements

for ACSE, ROSE, RTSE, and the Presentation and Session layers, so that

systems implemented according to these agreements can successfully

interoperate

.

5.1.1 References

All documents referenced in the Upper Layers section of these

agreements can be found in the REFERENCES section of this NIST

Implementation Agreements document.

5.2 SCOPE AND FIELD OF APPLICATION

The agreements in this section apply to all ASE agreements in this

document. Each ASE SIG chooses which protocols, functional units,

application contexts, and parameters it requires. These must be

listed in the "Specific ASE Requirements" section of this chapter.

5.3 STATUS

This text is stable as of December, 1989.

5.4 ERRATA

5.4.1 ISO Defect Solutions

This section lists the defect solutions from ISO which are currently recognized to be valid for the purposes of NIST

conformance

ISO 8326 defect solutions:

023, 024

ISO 8327 defect solutions:

037, 038

5-1
March 1990 (Stable)

5.4.2 Session Defect Solutions Correcting CCITT X.215 and

X.225

The following approved defect solutions have been integrated into

the current revisions of ISO 8326 and ISO 8327, but are not part

of CCITT X.215 and X.225 (1984). The defect solutions must be

incorporated into CCITT Session to insure conformance with ISO

Session.

ISO 8326 defect solutions:

004, 006, 007, 009, Oil, 012, 013, 014, 015, 016, 017, 020.

ISO 8327 defect solutions:

001, 003, 004, 005, 006, 007, 008, 009, 010, 012, 017, 018,

019, 026, 027, 030, 034, 035.

5.4.3 Errata approved at March. 1990 meeting

Errata to this chapter are marked with change bars; deleted text

is left but with strikeouts. The following table indicates the

section and type for each erratum.

COMMENT

added errata summary table

grammar

spelling

typographical

extraneous word

update to document reference

update to document reference

moved some abstract syntaxes so that all abstract syntaxes are listed under Presentation

requirements; deleted some Associated transfer syntax entries

so that there is only one reference

to Associated transfer syntax per

group of abstract sjmtaxes

changes to the encoding of two

FTAM abstract syntaxes: "NBS

abstract syntax ASl" and "NBS file

directory entry abstract syntax"

correction to abstract S3nitax

definition

added explanatory note on nil

application context

5-2

SECTION TYPE

5.4.3 editorial

5.5.2 editorial

5.8.3.7 editorial

5.8.5.1 editorial

5.8.5.1 editorial

5.8.7 editorial

5.9.4 editorial

5.12.1 editorial

5.12.1.1.1 technical

5.14.2 editorial

5.14.2 editorial
September 1990 (Stable)

5.5 ASSOCIATION CONTROL SERVICE ELEMENT

5.5.1 Introduction

This section details the implementation requirements for the

Association Control Service Element (ACSE) of the Application

layer as defined in ISO 8649 and ISO 8650.

5.5.2 Services

All ACSE services are within the possible scope of a NISTconformant system.

5.5.3 Protocol Agreements

5.5.3.1 Application Context

Values for and uses of Application Context names are determined by specific ASEs . Values used by NIST ASE SIGS are listed in the section entitled "Specific ASE

Requirements .

5.5.3.2 AE Title

AE- titles shall be implemented as specified in Amendment 1 to ISO 8650 (ISO 8650/AM1).

5.5.4 ASN.l Encoding Rules

When the ABRT APDU is used during the connection establishment

phase, Presentation layer negotiation is considered to be

complete, and the "direct-reference" component of EXTERNAL shall

not be present.

5.5.5 Connectionless

The connectionless ACSE protocol shall be implemented as specified in ISO DIS 10035.

No further agreements beyond those specified elsewhere in this

chapter have been made regarding this standard.

5-3
5.5.6 Result Parameter

September 1990 (Stable)

Refer to Working Implementation Agreements, March -199G7

September 1990.

5.6 ROSE

ROSE shall be implemented as specified in ISO DIS 9072-1.2 and ISO DIS

9072-2.2.

No further agreements beyond those specified elsewhere in this chapter

have been made regarding this standard.

5.7 RTSE

RTSE shall be implemented as specified in ISO 9066-1 and ISO 9066-2.

No further agreements beyond those specified elsewhere in this chapter

have been made regarding this standard.

5.8 PRESENTATION

5.8.1 Introduction

This section details the implementation requirements for the

Presentation layer as defined in the Presentation Service

Definition, ISO 8822, and the Presentation Protocol Definition,

ISO 8823.

The task of the Presentation layer is to carry out the

negotiation of transfer syntaxes and to provide for the

transformation to and from transfer syntaxes. The transformation

to and from a particular transfer syntax is a local

implementation issue and is not discussed within this section.

This section is concerned with the protocol agreements, and thus

is entirely devoted to the issues involved with the negotiation

of transfer syntaxes and the responsibilities of the Presentation

protocol

.

5.8.2 Service

Only the Kernel functional unit need be supported. The

Context Management and Context Restoration functional units

are outside the scope of these agreements.

5-4
March 1990 (Stable)

The requirement that the Presentation kernel functional unit

be implemented does not imply that any of the Session

functional units for expedited data, typed data, and

capability data and the corresponding Presentation service

primitives are required to be implemented.

5.8.3 Protocol Agreements

5.8.3.1 Transfer Syntaxes

The following transfer syntax must be supported

for all mandatory abstract syntaxes: the basic

encoding rules for ASN.l. This syntax is derived

by applying the basic encoding rules for ASN.l to

the abstract syntax (see the Basic Encoding Rules

for ASN.l, ISO 8825).

The number of transfer syntaxes proposed is

dependent upon the recognized transfer syntaxes

which are available to support the particular

abstract syntaxes used by an Application Entity.

5.8.3.2 Presentation Context Identifier

o A conformant implementation shall encode

Presentation context identifiers in the range 0 to

32,767.

o Implementations must be able to handle a minimum

of two Presentation contexts per connection.

5.8.3.3 Default Context

If the Presentation expedited data service is required, the

default context must be explicitly present in the P-CONNECT

PPDU at Presentation connect time.

5.8.3.4 P-Selectors

Local P-selectors shall be a maximum of four octets. This

applies only to P-selectors in PPDUs whose receipt by an NIST-conformant system normally results in either a P-CONNECT indication or a P-CONNECT confirmation being

issued.

5-5
March 1990 (Stable)

5.8.3.5 Provider Abort Parameters

No conformance requirements are implied by the use of either

the Abort-reason or the Event- identifier component of the

ARP-PPDU, The decision to include these parameters is left

up to the implementation issuing the abort.

5.8.3.6 Provider Aborts and Session Version

The Presentation Provider Abort PPDU (ARP-PPDU) shall be

present regardless of the Session version in effect for a given association. This precludes the use of indefinite

length encoding of an ARP-PPDU when Session Version 1 is in

effect

.

5.8.3.7 CPC-Tvpe

Implementations shall not use any CPC-type valvues in the

SS-user data parameter of the S-CONNECT unless more than

one transfer syntax is proposed for a single Presentation

context of the Presentation data values. Each CPC-type

represents a unique transfer syntax, so if more than one transfer syntax is proposed, CPC-type values may appear in

that SS-user-data parameter.

For a Presentation context for which the Basic Encoding

Rules are a proposed transfer syntax, all PDVs in the user

data parameter of the CP PPDU must be encoded first using

the Basic Encoding Rules and must be examined by the

receiving Presentation protocol machine. Following CPC-type

values may be examined or ignored at the receiver's option

(see ISO 8823, sec. 6.2.5.3).

5.8.3.8 Presentation-context-definition- result- list

No semantics are implied by the absence of the optional

Presentation-context-definition-result- list component of the

CPR-PPDU, This component is required if the Provider- reason

is absent in the CPR-PPDU. If the Provider-reason is

present, then the Presentation-context-definition-resultlist is optional.

5-6
5.8.3.9 RS-PPDU

June 1990 (Stable)

The Presentation-context- identifier- list shall not be

present when only the kernel functional unit is in effect.

5.8.4 Presentation ASN.l Encoding Rules

5.8.4.1 Invalid Encoding

If a received PPDU contains any improperly encoded data

values (including data values embedded within the User Data

field of a PPDU) and an abort is issued, then either an ARU

or an ARP shall be issued.

5.8.5 General

5.8.5.1 Presentation Data Value (PDV)

o A Presentation data value (PDV) is a value of a type in an abstract syntax, e.g., a value of an ASN.l type.

o A PDV may contain embedded PDVs in different contexts.

A change of context within a PDV is indicated by an

EXTERNAL. EXTERNAL implies an embedded PDV.

o A PDV cannot be split across PDV- lists in fully-encoded

user data.

o Fully-encoded-data that is a series of PDVs in the same Presentation context (e.g., grouped FTAM PDUs) shall

be encoded either as a single PDV- list (using the

octet-aligned choice) or as a series of PDV-lists, each

encoding either a single PDV (using the

s ingle -ASNl- type choice) or multiple PDVs (using the

octet-aligned choice) . Note that receivers must accept

any of the above encodings.

5.8.6 Connection Oriented

The Transfer- syntax-name component of a PDV-list value shall be

present in a CP PPDU if and only if more than one transfer syntax

name was proposed for the Presentation context of the

Presentation data values. The Transfer- syntax-name component of

a PDV-list value shall always be present in a CPC-type. If only

the Kernel functional unit is negotiated, then the

5-7
June 1990 (Stable)

Transfer- syntax-name component of a PDV-list value shall only

appear in the CP PPDU and CPC-type.

5.8.7 Connectionless

The connectionless Presentation protocol shall be implemented as specified in ISO DIS 9576.

The Transfer- syntax-name component of a PDV-list value shall be

present in a UD PPDU if and only if more than one transfer

syntax name was proposed for the Presentation context of the

Presentation data values. The Transfer- syntax-name component of

a PDV-list value shall always be present in a UDC-type. The

Transfer -syntax -name component of a PDV-list value shall only

appear in the UD PPDU and UDC-type.

No further agreements beyond those specified elsewhere in this

chapter have been made regarding this standard.

SESSION

5.9.1 Introduction

This section details the implementation requirements for the

Session layer as defined in the Session Service Definition, ISO

8326 and the Session Protocol Definition, ISO 8327.

5.9.2 Services

The following functional units are within the scope of a NISI

conformant system.

Kernel

Duplex

Expedited Data

Resynchronize

Exceptions

Activity Management

Half -duplex

5-8
March 1990 (Stable)

Minor Synchronize

Major Synchronize

Typed Data

5.9.3 Protocol Agreements

5.9.3.1 Concatenation

When a category 0 SPDU is concatenated with a category 2 SPDU, the category 0 SPDU shall not contain User Data.

Extended concatenation is not required and can be refused

using the normal negotiation mechanisms of the Session

protocol

.

5.9.3.2 Segmenting

Session segmenting is not required and can be refused using

the normal negotiation mechanisms of the Session protocol.

All conformant implementations shall be able to interwork

without Session segmenting.

5.9.3.3 Reuse of Transport Connection

Reuse of a Transport connection is not required and can be

refused.

5.9.3.4 Use of Transport Expedited Data

The Session use of Transport expedited service is supported.

The meaning of "supported" is specified in section 3.1 of

ISO DISP AFTnn-1.

Note: It is recommended to request and use this feature.

5.9.3.5 Use of Session Version Number

Session Versions 1 and 2 are recognized. Each relevant

NIST SIG chooses the version or versions of Session which it

requires for a particular implementation phase, and these

choices are documented in section 5.12.

5-9
March 1990 (Stable)

Session Version 2 specifies the use of unlimited user data

during connection establishment as dictated by the AD 2 to

ISO 8327 to Incorporate Unlimited User Data,

All Session Version 1 implementations must be able to

negotiate Version 1 operation when responding to a CONNECT

(CN) SPDU proposing both Version 1 and Version 2.

In addition, all Session Version 1 implementations, upon

receipt of a CONNECT (CN) SPDU proposing only Version 2,

should respond with a REFUSE (RF) SPDU containing a Reason

Code indicating that the proposed version is not supported.

Until pending defect reports are adopted, implementations

may disconnect.

If Session Versions 1 and 2 are both proposed in the

CONNECT (CN) SPDU, then the maximum length of the User Data

parameter value in the CONNECT (CN) SPDU shall be 512 octets

and a PGI field of 193 shall be associated with this

parameter. This implies that an implementation supporting

both Session Versions 1 and 2 can establish a connection

with an implementation supporting only Version 1.

If only Session Version 2 is proposed in the CONNECT (CN)

SPDU, then the maximum length of the Session User Data

parameter value of the S-CONNECT service request shall be

10,240 octets. This restriction implies that the OVERFLOW

ACCEPT (OA) SPDU and CONNECT DATA OVERFLOW (CDO) SPDU are not used. If the length of the User Data parameter value is no greater than 512 octets, then an associated PGI field of

193 shall be used, otherwise a PGI field of 194 shall be

used.

When Session Version 2 is negotiated, then in all SPDUs the

maximum length of the User Data parameter value with an associated PGI field of 193 shall be 10,240 octets. NISTconformant Session Version 2 implementations need only

support the maximum data lengths specified in the Specific

ASE Requirements section.

5.9.3.6 Receipt of Invalid SPDUs

Upon receipt of an invalid SPDU, the SPM shall take any

action in A. 4. 3 of the Session Protocol Definition ISO/IS

8327 except Action d.

5-10
June 1990 (Stable)

5.9.3.7 Invalid SPM Intersections

If the conditions described in A. 4. 1.2 of the Session

Protocol Definition ISO/IS 8327 are satisfied, the SPM shall

always take the actions described by A. 4. 1.2 a.

Note: This implies that no S-P- EXCEPTION -REPORT

indications will be generated nor EXCEPTION

REPORT SPDUs sent due to invalid intersections of

the Session state table resulting from received

SPDUs

.

5.9.3.8 S-Selectors

S-selectors shall be a maximum of 16 octets.

5.9.4 Connectionless

The connectionless Session protocol shall be implemented as specified in ISO IS 9548.

No further agreements beyond those specified elsewhere in this

chapter have been made regarding this standard.

10 UNIVERSAL ASN . 1 ENCODING RULES

5. 10.

1

TAGS

The maximum value of an ASN.l basic encoding tag that need be

handled by an NIST-conformant implementation shall be 16,383.

This is the maximum unsigned number that can be represented in 14

bits, therefore, the maximum encoding of a tag occupies 3 octets.

5.10.2 Definite Length

The maximum value of an ASN.l length octets component that need

be handled by an NIST-conformant implementation shall be

4,294,967,295. This is the maximum unsigned integer that can be

represented in 32 bits, therefore, the maximum encoding of a length octets component will occupy 5 octets. Also, note this

restriction does not apply to indefinite length encoding.

5.10.3 EXTERNAL
June 1990 (Stable)

It is assumed that "Presentation layer negotiation of encoding

rules" is always in effect, and therefore clause 32.5 of the

Specification of ASN.l, ISO 8824 never applies.

a. If a data value to be encapsulated in an EXTERNAL type is an instance of a single ASN.l type encoded according to the

Basic Encoding Rules for ASN.l, then the option

" s ingle - ASN. 1- type" shall be chosen as its encoding.

b . If a data value to be encapsulated in an EXTERNAL type is

encoded as an integral number of octets, and case a. does

not apply, then the option "octet-aligned" shall be chosen

as its encoding.

5 . 10.4 Integer

o Any incidence of an ASN.l INTEGER type defined in an abstract syntax describing protocol control information

must be encoded so that the length of its contents octets is no more than four octets, unless an explicit NIST agreement

to the contrary is made for a specific INTEGER type.

5. 10.5 String Types

o ' The contents octets for a constructed encoding of a BIT

. STRING, OCTET STRING, or character string value consists of

the complete encoding of zero, one, or more data values, and

the encoding of these data values must be primitive.

5 . 10. 6 Bit String

o Unless otherwise specified in the abstract syntax

definition, each bit named in a BIT STRING type used in that

abstract syntax definition shall be explicitly encoded in

the associated BIT STRING value, even if it is part of a string of trailing zero bits.

Extra trailing bits beyond the exact number of bits which

correspond to the complete list of the named bits specified

shall never be encoded. This rule applies to all BIT STRING

types unless stated otherwise in the standards.

5-12
5.11 CHARACTER SETS

September 1990 (Stable)

See aligned section of Working Implementation Agreements dated

December 1989.

5.12 CONFORMANCE

In order for an implementation to be in conformance with the NIST

implementors ' agreements, the rules below shall be followed.

o A conformant implementation must meet all of the requirements of

this specification. All documents referenced in the Upper Layers

section shall be used as the supporting documents for all

implementations of ACSE, ROSE, RTSE, Presentation, or Session.

The full references for these documents are in the REFERENCES

section.

o NIST-conformant implementations shall be ISO conformant. PICS

may contain limitations on length or value aspects of a protocol.

PICS of NIST-conformant systems shall not contain restrictions

more severe than those in these implementation agreements.

The following list for each ASE the corresponding NIST SIG's

requirements of and restrictions on ACSE, ROSE, RTSE,

Presentation, and Session.

All listed requirements and restrictions shall be included in an NIST-conformant system and shall be implemented in accordance

with these NIST Implementor ' s agreements.

Note: An implementation may abort a connection if the

constraints specified in these agreements are violated.

5.12.1 Specific ASE Requirements

5.12.1.1 FTAM

5.12.1.1.1 Phase 2

ACSE Requirements:

all

Application Contexts:

o "ISO FTAM

5-13
September 1990 (Stable)

{ iso(l) standard(O) 8571

application-context iso-ftam(l) } - implies the use of the ACSE and the

FTAM ASE.

A -value -is -defined -for -the -AE -Title -only -te

satisfy -the -FTAM -requirement -for -exchanging -fields

of -this -typeT

This -value -does -not -identify -an -Application -Entity

and -carries -no -semantics - -The -AE -title -maps -onto

the -AP -title -and -the -AE -qualifier .- - -If -the -AE

title -is -used ,- -then -both -AP -title - (^an -GBJEGT

IDENTIFIER> -and -AE -qualifier - (-an -INTEGER> -must -be

sentr

The -value -for -the -AP -title -is -f -1 -S - -9999 -1 ftam-nil-ap-title -f?} -at -this -time .- - -Values -for

the -AE -qualifier -are -outside -the -scope -of -these

agreements

7

A value is defined for the AE Title only to

satisfy the FTAM requirement for exchanging fields

of this type. This value does not identify an Application Entity and carries no semantics.

If the AE title is used, AE- title- form2 shall be

supported. Support of AE- title-form2 includes

support of AP- title-form2 and AE-qualifier-form2

.

The value for the AP title is { 1 3 9999 1 ftam-nil-ap-title (7) } at this time. Values for

the AE qualifier are outside the scope of these

agreements

.

The use of AP invocation identifiers and AE

invocation identifiers by FTAM is outside the

scope of these agreements

.

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts:

o At least 3 Presentation Contexts must be

supported.

5-14
Abstract Syntaxes:

Abstract Syntaxes for

Implementations

o "ISO 8650-ACSEl"

September 1990 (Stable)

conformant

5- 14-1
1\
March 1990 (Stable)

{ joint-iso-ccitt(2)

association-control (2)

abstract- S3mtax(l) apdus(O) versionl(l)

)

o "FTAM-PCI"

{ iso(l) standard(O) 8571

abstract "Syntax( 2) ftani-pci(l) }

Asseei-afced -Transfer -Syi^feaxt o '^Basie -Encoding -of -a -single -ASK rl type"

t- -j-oinc-i90-eeifct(-2> -asnlr(-lr)

basie-eneodingfl)- -)

o "FTAM unstructured binary abstract

syntax"

{ iso(l) standard(O) 8571

abstract-syntax(2)

unstructured-binary(4) )

-Assoeiafeed -Transfer -Syntaxf

o '^Basie -Encoding -of -a -singTbe -ASN .-1 t3^e«

f -j-oinfe-iso-eeitfe(-2)--asnlf]r)

basic -encoding -)

Editor's Note: In Definitions below, "NBS"

designation will be preserved.

Abstract Syntaxes Depending on Implementation Profile

o "FTAM-FADU"

{ iso(l) standard(O) abstract-s3mtax(2)

ftain-fadu(2) )

Asaoeiafeed -Transfeif -Syntax f o '^Basie -Encoding -of -a -single -ASN .-1 type"

i- -j-oinfc-tso-eeittf2>-a3n]r(-t)

basic-encoding (-!:>

o "FTAM unstructured text abstract S3mtax"

{ iso(l) standard(O) 8571

abstract- syntaxC 2) unstructured- text (3)

}

Associated -Transfer -Syntaxt

5-15
March 1990 (Stable)

o '^Basie -Encoding -of -a -single -ASN .-1 feype"

t -j-oint-i90-eeifetf2> -asntft)

baste-eneodtngf

o "NBS abstract syntax ASl"

{ iso identified-organization oiw(14)

ftanisig(5) abstract-syntax(2) nbs-asl(l)

}

Assoeiafeed -Ttansf -Syntax

t

o '^Basie -Encoding - -of -a -single -ASN .-1 type"

{- -j-©tnfe-is©-eeifetf2> -asntf1)

basic -encoding (•!) -)

o "NBS file directory entry abstract

syntax"

{ iso identified-organization oiw(14)

ftamsig(5) abstract-syntax(2) nbs-as2(2)

}

Associated Transfer S3mtax:

o "Basic Encoding of a single ASN.l

type"

{ joint-isc-ccitt(2) asnl(l)

basic-encoding(l) )

Editor's Note: The changes above involving "0IW(14)" were

not explicitly mentioned at the March 1990

Plenary, but were implied from a correspondingly approved FTAM motion.

Session Requirements:

Session Functional Units:

o kernel

o duplex

¥ersion Nussber: 2

Maximum size of User Data parameter field: 10,240

Session Options:

Session Functional Units:

o resynchronize

only a Resjmchronize Type value of

"abandon"

5-16
March 1990 (Stable)

o minor synchronize

Note: The minor synchronize

functional unit is

required whenever the

resynchronize functional

unit is available.

The default value for Minor Sync Point Sync

type item shall always be used, i.e.,

explicit confirmation is required.

ASN.l Encoding Requirements

Some INTEGER types of the FTAM PCI may exceed the

maximum size specified in the UNIVERSAL ASN.l

ENCODING Rules. See the Range of values for

INTEGER type Parameters of the FTAM chapter.

5.12.1.2 MHS

5.12.1.2.1 Phase 1 (1984 X.400)

Session Requirements:

Session Functional Units:

o kernel

o half-duplex

o exceptions

o activity management

o minor synchronize

Version Number: 1

Maximum size of User Data parameter field: 512

Session Notes:

o Restricted use is made by the RTS of the

Session services implied by the

functional units selected.

Specifically,

No use is made of S-TOKEN-GIVE

,

and

S- PLEASE-TOKENS only asks for the

data token.

5-17
March 1990 (Stable)

o In the S -CONNECT SPDU, the Initial

Serial Number should not be present.

o The format of the Connection Identifier

in the S -CONNECT SPDU is described in

Version 5 of the X.400-Series

Implementors ' Guide.

5.12.1.2.2 Phase 2. Protocol Pi (1988 X.400)

ROSE Requirements;

ROSE is not used.

RTSE Requirements:

o Monologue

o TWA - optional

o checkpointing

.minimum checkpoints ize = 1 .minimum windows ize = 1

, o no checkpointing

Notes

o Monologue Association:

initiator keeps initial turn

APDUs are transferred from

initiator to responder only

no turn passing

only the initiator effects the

orderly release of an association

o Two way alternate Association

the initiator may keep or pass the

initial turn, at binding

APDUs are transferred by the holder

of the turn

only the initiator effects the

orderly release of an association,

when it possesses the turn

ACSE Requirements:

As per Phase 2, Protocol P7

.

Application Contexts:

o "MTS-transfer-protocol-1984" - mandatory

o "MTS-transfer-protocol" - mandatory

o "MTS- transfer" - mandatory

5-18
March 1990 (Stable)

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts:

o at least 3 must be supported

Abstract Syntaxes:

o "ISO 8650-ACSEl"

{ joint-iso-ccitt (2) association-control (2)

abstract-syntax(l) apdus(O) versionl(l) }

o "MTS-RTSE"

o "MTSE"

Associated Transfer Syntax:

o "Basic Encoding of a single ASN.l

type"

[ joint-iso-ccitt(2) asnl(l)

basic-encoding(l) )

Session Requirements:

As per Phase 2 , Protocol P7

.

5.12.1.2.3 Phase 2. Protocol P7 (1988 X.400)

ROSE Requirements:

Operation and association classes are used as per

the standard.

RTSE Requirements:

o TWA

o normal -mode

o checkpointing

.minimum checkpoints ize = 1 .minimum windows ize = 1 o no checkpointing

Notes

o Monologue Association:

initiator keeps initial turn

APDUs are transferred from

initiator to responder only

no turn passing

only the initiator effects the

orderly release of an association
March 1990 (Stable)

o Two way alternate Association

the initiator may keep or pass the

initial turn, at binding

APDUs are transferred by the holder

of the turn

only the initiator effects the

orderly release of an association,

when it possesses the turn

ACSE Requirements

all

The use of AP-TITLE, AE-QUALIFIER,

AP- INVOCATION- ID, and AE-INVOCATION-ID is not

recommended; however, a receiving entity must be

capable of ignoring them (if present) without

refusing the connection.

Application Contexts:

o "MS-access" - mandatory; normal mode

o "MS-reiiable-access" - optional; normal

mode

Absferaet -Syntaxes

t

o '^IS0-863G-AGSEt"

f -j-otnt-i:so-eeitfe(-2)

assoeiation-eontrol f 2)

abstract-syntax flr> -apdusfO)- -versiontf1)

: y

Associated -Transfer -Syntaxf

o -'^Baste -Encoding -of -a -single -ASN .-1 type"

{- -j-oint-iso-ceitt(^2> -asntft)

basic-encoding (-t)- -)

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts:

o at least 5

Abstract Syntaxes:

o "ISO 8650-ACSEl"

{ joint-iso-ccitt(2)

association-control (2)

abstract-syntax( 1 ) apdus(O) versionl(l)

)

5-20
March 1990 (Stable)

o MSBind/MSUnbind (with or without RISE)

o MSSE (Message Submission)

o MASK (Message Administration)

o MRSE (Message Retrieval)

Associated Transfer Syntax:

o "Basic Encoding of a single ASN.l

type"

{ joint-iso~ccitt(2) asnl(l)

basic-encoding(l) )

Session Requirements:

Session Functional Units:

o kernel

o half-duplex

o exceptions

o activity management

o minor synchronize

Version Nusoiber: 2

Maximum size of User Data parameter field: 10,240

Session Notes:

o MHS proposes both versions 1 and 2 for

pass through mode (X.410 mode), but only

version 2 for normal mode,

o Restricted use is made by the RTS of the

Session services implied by the

functional units selected.

Specifically,

No use is made of S-TOKEN-GIVE,

and

S- PLEASE -TOKENS only asks for the

data token.

o In the S -CONNECT SPDU, the Initial

Serial Number should not be present.

o The format of the Connection Identifier

in the S-CONNECT SPDU is described in

Version 5 of the X.400-Series

Implementors ' Guide.

5-21
March 1990 (Stable)

5.12.1.2.4 Phase 2. Protocol P3 (1988 X.400)

ROSE Requirements:

As per Phase 2, P7.

RTSE Requirements:

As per Phase 2 , P7

.

4CSE_Jle£ulremepJ^l

As per Phase 2, P7

.

Application Contexts

o "MTS- access" - mandatory

o "MTS-reliable-access" - optional

o "MTS-forced-access" - mandatory

o "MTS-forced- reliable-access" - optional

Presentation Requirements:

As per Phase 2 , P7

.

Session Requirements:

As per Phase 2, P7.

5.12.1.3 DS

5.12.1,1,1 Phase..!

ACSE Requirements:

all

Application Contexts:

o "id-ac-directoryAccessAC"

{ joint-lsO"Ccitt(2) ds(5) 3 1 }

o "id-ac-directorySy,3ten)AC"

{ joint-i£o-ccitt(2) ds(5) 3 2 )

Absfcraet -Syntaxes

f

o 'ilSG-S&SO-AGSEl"

f- -j-otnfe-is©-eei:tfe(-2)

assoeiation - control: (-2)

abstraec -syntax (^lr> -apdu3(-G> -version! 6^)

>

Associated -Tx^aBsfer -Syntax; t 0 '^Basi-e -Bn^odtRg -©f -a -single -ASN .-1 type"

5-22
March 1990 (Stable)

{--j-oinfe-iso-eeitfef2> -asnlft)

basie-eneodingf1> -)

o '^id-as-direefeoryAeeessAS"

j-otnfe-iso-eettfe62> -d»65> -9 -t -)

Associated -Transfer -Syntaxf

o '^Basic -Encoding -of -a -single

ASN.-t-feype"

f -j-oinfe-iso-ceitfef2> -asntft)

basic -encoding (!:)

o '"^id-as-direefeorySysteiaAS"

{- -j-oinfe-iso-ccitt f2> -dsf5> -9 -2 -)

Associated -Transfer -Synfeaxt o '^Basic -Encoding -of -a -single -ASN .-1 type"

(- -j-oint-iso-eeittf2)- -asntft)

basic -encoding (•!:> -}

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts:

o At least 2 Presentation Contexts must be

supported.

Abstract Syntaxes:

o "ISO 8650-ACSEl"

{ joint-iso-ccitt(2)

association-control(2)

abstract- s)mtax(l) apdus(O) versionl(l)

)

o "id-as-directoryAccessAS"

joint-iso-ccitt(2) ds(5) 9 1 )

o "id-as-directorySystemAS"

{ joint-iso-ccitt(2) ds(5) 9 2 )

Associated Transfer Syntax:

o "Basic Encoding of a single

ASN.l type"

{ joint-iso-ccitt(2) asnl(l)

basic -encoding(l) )

Session Requirements:

5-23
March 1990 (Stable)

Session Functional Units:

o kernel

o duplex

Version Number: 2

Maximuni size of User Data parameter field:

10,240

5.12.1.4 Virtual Terminal

5.12.1.4.1 Phase la

ACSE Requirements:

all

Application Contexts:

o "ISO VT"

{ iso(l) standard(O) 9041

application-context(l) } - implies the use of the ACSE and the VT ASK

Abstract -Syntaxes

t

o '^ISG-SSSG-AGSEt"

f -j-oinfe-iso-eeittf2)- -a3soeiation-eontrolr(-2)

absfe]faefe-synfeax(-lr> -apdus(-0> -versiont^^t)-

Associated -Transfer -Syntaxt

o -'^Basie -Encoding -of -a -single -ASN .-1 -type"

{- -joint-iso-eeitt(-2> -asnlf t)

basic-encoding (•]:>

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts:

o at least 2 must be supported

Abstract Syntaxes:

o "ISO 8650-ACSEl"

{ joint~iso-ccitt(2) association-control(2)

abs tract- syntax( 1 ) apdus(O) versionl(l) }

o "VT Basic"

{ iso(l) standard(O) 9041 abstract-syntax(2)

)

5-24
September 1990 (Stable)

Associated Transfer Syntax:

o "Basic Encoding of a single ASN.l type"

{ joint-iso-ccitt(2) asnl(l)

basic-encoding(l) }

Session Requirements:

Session Functional Units:

o kernel

o duplex

o expedited data

o major synchronize

o resynchronize

- only a Resjmchronize Type value of

"restart"

o typed data

Version Number: 2

Maxintum size of User Data parameter field: 10,240

Session Options:

o expedited data

5.12.1.4.2 Phase lb

ACSE Requirements:

all

Application Contexts:

o "ISO VT"

{ iso(l) standard(O) 9041

application-context (1) ) - implies the use of the ACSE and the

VT ASE

Presentation Requirements:

Presentation Functional Units:

o kernel

Presentation Contexts

o at least 2 must be supported

Abstract Syntaxes:

o "ISO 8650-ACSEl"

{ joint-iso-ccitt(2)

assoclation-control(2)

5-25
September 1990 (Stable)

abstract-syntax(l) apdus(O) versionl(l)

)

o "VT Basic"

{ iso(l) standard(O) 9041

abstract-syntax(2) )

Associated Transfer Syntax:

o "Basic Encoding of a single ASN.l

type"

( joint-iso-ccitt(2) asnl(l)

basic-encoding(l) }

Session Requirements:

Session Functional Units:

o kernel

o duplex

o half-duplex

o expedited data

o major synchronize

o resynchronize

- only a Resynchronize Type value of

"restart"

o typed data

Version Number: 2

Maximum size of User Data parameter field: 10,240

Session Options:

o expedited data

5.12.1.5 MMS

See Working Implementation Agreements Document, March -1:9907

September 1990.

5-26
September 1990 (Stable)

5.12.1.6 Transaction Processing

See Working Implementation Agreements Document, March -199Gt

September 1990.

5-27
September 1990 (Stable)

5.13 APPENDIX A: RECOMMENDED PRACTICES

The optional "Reflect Parameter Values" parameter in the Provider

ABORT SPDU shall be encoded so as to represent the Session connection

state, the incoming event and the first invalid SPDU field exactly at

the moment a protocol error was detected.

The first octet encodes the Session state as a number relative to 0 as detailed in table 5.1.

The second octet encodes the incoming event as a number relative to 0 as detailed in table 5.2.

The third octet contains the SI, PGI , or PI Code of any SI field, PGI

unit or PI unit in error.

Note: The remaining 6 octets are undefined herein.

5-28
March 1990 (Stable)

Table 5.1. Session States

State Rel .# Description

1 0 Idle, no transport connection

IB 1 Wait for T-connect confirm

IC 2 Idle, transport connected

2A 3 Wait for the ACCEPT SPDU

3 4 Wait for the DISCONNECT SPDU

8 5 Wait for the S-CONNECT response

9 6 Wait for the S -RELEASE response

16 7 Wait for the T-DISCONNECT indication

713 8 Data Transfer state

lA 9 Wait for the ABORT ACCEPT SPDU

4A 10 Wait for the MAJOR SYNC ACK SPDU or PREPARE

SPDU

4B 11 Wait for the ACTIVITY END ACK SPDU or PREPARE

SPDU

5A 12 Wait for the RESYNCHRONIZE ACK SPDU or PREPARE

SPDU

5B 13 Wait for the ACTIVITY INTERRUPT SPDU or PREPARE

SPDU

5C 14 Wait for the ACTIVITY DISCARD ACK SPDU or PREPARE

SPDU

6 15 Wait for the RESYNCHRONIZE SPDU or PREPARE

SPDU

lOA 16 Wait for the S-SYNC-MAJOR response

lOB 17 Wait for the S -ACTIVITY- END response

llA 18 Wait for the S -RESYNCHRONIZE response

IIB 19 Wait for the S-ACTIVirf- INTERRUPT response

lie 20 Wait for the S-ACTIVITY-DISCARD response

15A 21 After PREPARE, wait for the MAJOR SYNC ACK SPDU or the

ACTIVITY END ACK

15B 22 After PREPARE, wait for the RESYNCHRONIZE SPDU or the

ACTIVITY DISCARD SPDU

15C 23 After PREPARE, wait for the RESYNCHRONIZE ACK SPDU, or the ACTIVITY INTERRUPT ACK SPDU or the ACTIVITY DISCARD

ACK SPDU

18 24 Wait for GIVE TOKENS ACK SPDU

19 25 Wait for a recovery request or SPDU

20 26 Wait for a recovery SPDU or request

21 27 Wait for the CAPABILITY DATA ACK SPDU

22 28 Wait for the S- CAPABILITY- DATA response

ID 29 Wait for the CONI^fECT DATA OVERFLOW SPDU

2B 30 Wait for the OVERFLOW ACCEPT SPDU

15D 31 After PREPARE, wait for the ABORT SPDU

5-29
March 1990 (Stable)

Table 5.2. Incoming Events

Ke i . w Description

SCONreq 0 S- CONNECT request

SCONrsp+ 1 S -CONNECT accept response

SCONrsp- z S -CONNECT reject response

SDTreq 3 S-DATA request

SRELreq 4 S -RELEASE request

SRELrsp+ 5 S -RELEASE accept response

SUABreq 6 S-U- ABORT request

TCONcnf 7 T-CONNECT confirmation

TCONind 8 T-CONNECT indication

TDISind 9 T-DISCONNECT indication

TIM 10 Time out

A A AA i iA t> /"XD T A TT T)*T' AJiUKi ACUhr

i

AB-nr 12 ABORT - no reuse AO ALUhr

i

CN 1 A CONNECT

DN 15 DISCONNECT

DT 16 DATA TRANSFER

FN-nr 1 / FINISH - no reuse RF-nr 18 REFUSE - no reuse SACTDreq 19 S -ACTIVITY- DISCARD request

SACTDrsp 20 S -ACTIVITY- DISCARD response

bAL i iLreq 0 1 b-ALiiVii i-hlNU request

bAuifcrsp 0 0 b-ALiiiViii-E-JNU response

CbAui A CTlireq fan 0 1 Z J b - AOi 1 V i i 1 - iJN i liKKUr i request

C A r"TT vr^»^ Z4 b-AOiiVii I -iJNitKKuri response

bAOiKreq Z J b-ACiiVii i-KhbUMh. request

O A ^T^C UAH bAOibreq Zo b-ACiiVii Y-biAKi request

O T\ _ _ bODreq z / b-CAFAliiLiii-DAiA request

bt/Ursp Zo b-CArAciLii i-UAiA response

SCGreq zy S- CON IROL- GIVE request

bhXreq o -EArciDi ILD-DAiA request

SGTreq il S -TOKEN -GIVE request

br ireq JZ b- 1 OKLN -

r

LKAd h request

bKhLrsp- b-KhLhiAbb response reject

bKb iNreq (a; j4 b -REbYNCnRONlZh request aDanaon

bKb iJNreq )

"3 1^ J J b-Ktib iNCriKUiNiZh. request restart

SRSYNreq(s) 36 S-RESYNCHRONIZE request set

SRSYNrsp 37 S-RESYNCHRONIZE response

SSYNMreq 38 S-SYNC-MAJOR request

SSYNMrsp 39 S- SYNC -MAJOR response

SSYNmreq 40 S- SYNC -MINOR request

SSYNmrsp 41 S- SYNC -MINOR response

STDreq 42 S-TYPED-DATA request

SUERreq 43 S-U-EXCEPTION-REPORT request

5-30
March 1990 (Stable)

Table 5.2. Incoming Events Continued

Event Rel .# Description

AB-r 44 ABORT - reuse SPDU

AD 45 ACTIVITY DISCARD SPDU

ADA 46 ACTIVITY DISCARD ACK SPDU

AE 47 ACTIVITY END SPDU

AEA 48 ACTIVITY END ACK SPDU

AI 49 ACTIVITY INTERRUPT SPDU

AIA 50 ACTIVITY INTERRUPT ACK SPDU

AR 51 ACTIVITY RESUME SPDU

AS 52 ACTIVITY START SPDU

CD 53 CAPABILITY DATA SPDU

CDA 54 CAPABILITY DATA ACK SPDU

ED 55 EXCEPTION DATA SPDU

ER 56 EXCEPTION REPORT SPDU

EX 57 EXPEDITED DATA SPDU

FN-r 58 FINISH - reuse SPDU

GT 59 GIVE TOKENS SPDU

GTA 60 GIVE TOKENS ACK SPDU

GTC 61 GIVE TOKENS CONFIRM SPDU

MAA 62 MAJOR SYNC ACK SPDU

MAP 63 MAJOR SYNC POINT SPDU

MIA 64 MAJOR SYNC ACK SPDU

MIP 65 MINOR SYNC POINT SPDU

NF 66 NOT FINISHED SPDU

PR-MAA 67 PREPARE (MAJOR SYNC ACK) SPDU

PR-RA 68 PREPARE (RESYNCHRONIZE ACK) SPDU

PR-RS 69 PREPARE (RESYNCHRONIZE) SPDU

PT 70 PLEASE TOKENS SPDU with Token Item

Parameter

RA 71 RESYNCHRONIZE ACK SPDU

RF-r 72 REFUSE - reuse SPDU

RS-a 73 RESYNCHRONIZE - abandon SPDU

RS-r 74 RESYNCHRONIZE - restart SPDU

RS-s 75 RESYNCHRONIZE - set SPDU

TD 76 TYPED DATA SPDU

CDO 77 CONNECT DATA OVERFLOW SPDU

OA 78 OVERFLOW ACCEPT SPDU

PR-AB 79 PREPARE (ABORT) SPDU

5-31
March 1990 (Stable)

14 APPENDIX B: OBJECT IDENTIFIER REGISTER

5.14.1 Re gister Index

Each entry in the index contains an object identifier value and a reference to the section describing the object identifier's use.

1. { iso(l) identified-organization(3) oiw(14) ulsig(8)

application-context(l) nil(l) } is defined in section

5.14.2.

2, { iso(l) identified-organization(3) oiw(14) ulsig(8)

abstract-syntax(2) octet-string(l) ) is defined in section

5.14.2.

5 . 14 . 2 Object Identifier Descriptions

1. { iso(l) identified-organization(3) oiw(14) ulsig(8)

application-context( 1 ) nil(l) )

This application context may be used by applications having

a prior agreement regarding the application context.

Note: This value is intended to be used by private

applications that have an a priori agreement

concerning the set of ASEs, related options,

and any other information necessary for the

interworking of AEs on an application

association. This value does not identify

any specific application context and cannot

be used to identify the intended

communications environment for the

application association. Therefore, it is

strongly recommended that private

applications define and register an object

identifier for their application context.

2. { iso(l) identified-organization(3) oiw(14) ulsig(8)

abstract-syntax(2) octet-string(l) )

NIST-GIW-UtSIG-AS- h==BEGIN

octet-string -- -singte-oetet-string h=-GGTET-STRINGDEFINITIGNS END

NIST-OIW-ULSIG-AS-octet- string

DEFINITIONS : := BEGIN

Single-octet-string : := OCTET STRING

END

5-32
March 1990 (Stable)

This abstract syntax may be used by applications having a prior agreement regarding the content of the octet string.

5-33

December '89

REGISTRATION AUTHORITY PROCEDURES FOR THE OS I IMPLEMENTORS WORKSHOP

Editor's Note: Previous material in this section has been deleted and

is no longer applicable.

This chapter establishes the policies and procedures for the

registration of technical objects defined by the OSI Implementors

Workshop. Procedures for registering operational and administrative

objects, such as the MHS ADMD and PRMD names and addresses, are outside the scope of this chapter.

6.1 INTRODUCTION AND SCOPE

6.1.1 What is Registration?

In order to communicate, it is necessary to identify the objects

involved in communication. These objects have names and

addresses. A name identifies an object within the domain of a registration authority. An address is a name that is used to

specify the physical or logical location of an object,

OSI names and addresses consist of attributes which are hierarchical in nature and which combine to identify or locate an

OSI object unambiguously. Since the relationship between the

components of a name or address is hierarchical, it follows that

the registration authority for names and addresses should also be

hierarchical. A governing organization does not always have

sufficient knowledge of organizations lower in the hierarchy to

assign values within those organizations. Thus, an approach

frequently taken is to delegate registration authority to the

lower organizations

.

Hierarchy implies an inverted tree- like structure where the

number of objects increases from the root of the tree to the

leaves of the tree. At the root of the tree, there is one designator that has the greatest scope of authority (largest

domain). This designator assigns identifier values to objects

under its authority. Each of these objects has a smaller scope

of authority than the objects immediately above and may create

zero, one, or many subauthorities at the next- lower level. The

number of levels in such a tree -like structure is arbitrary.

6-1
December '89

6.1.2 Scope

This chapter defines registration procedures for OSI

Implementors Workshop (OIW) information objects and identifies

additional registration requirements. These procedures shall be

used by the Special Interest Groups (SIGs) of the Workshop to

register information objects used in OSI communications according

to the OIW Agreements Document.

In this chapter, the OIW and the SIGs themselves are assigned

arcs in the object identifier tree. These arcs are for OIWspecified objects. The SIGs should note that, as national and

international registration authorities are established, objects

of interest beyond the Workshop are more appropriately registered

by a higher level in the hierarchy. This will allow more

widespread acceptance of the registered objects.

This chapter is structured as follows: section 6.2 describes the

information objects that need to be registered. Section 6.3

describes a registration procedures for OIW object identifiers.

> Appendix A lists the object identifier component values assigned

to the OIW and the SIGs. Appendix B discusses object

identifiers used in the 1987 and 1988 Stable Implementation

Agreements. The appendices are integral parts of this

specification.

6.2 REGISTERED INFORMATION OBJECTS

If networks are to interoperate as envisioned in the OSI model, there

must be a universal open and agreed upon naming schema. There are many information objects that fall under this requirement.

Some of the following objects are registered in the standards, some

are registered by OIW and others by other registration authorities.

An example list of objects to be registered is:

o Application-process- titles

o Application-entity- titles

o Abstract syntaxes

o Transfer syntaxes

o Application-contexts

o MHS

ADMD names

PRMD names Organization names Encoded information types

Extended body part types

Extensions

etc

.

6-2
March 1990 (Stable)

o Object Identifier values

o ASN.l modules

o Directory

Relative distinguished names Attribute types

Attribute syntaxes

Object classes

Encryption algorithms

etc

.

o VT

Profiles

Reference information objects

etc

.

o Network management objects

o Network layer addresses

o System titles

o FTAM

Document types

Constraint sets

etc

.

o etc

.

The OIW Registration Authority shall only administer information

objects created by the OIW Agreements Document that are identified by

the ASN.l type OBJECT IDENTIFIER. Figure 6.1 illustrates the

structure of the object identifier component value for OIW.

{ iso identified-organization oiw(14) }

iso(l)

identified-organization( 3)

oiw(14)

Figure 6.1. Structure of Object Identifier for OIW.

6-3
March 1990 (Stable)

I As an example figure 6.2 shows the object identifier component value

I for an example object.

{ iso identified- organization oiw(14) rasig(13) example(O))

iso(l)

identified-organization(3)

oiw(14)

rasig(13)

example (0)

I Figure 6.2. Structure of an Object Identifier for an Example

I Object for the Registration Authority SIG of OIW.

The ISO 6523 Registration Authority has assigned an International Code

Designator (ICD) value of 14 to OIW, and OIW has assigned a unique

object identifier component value to each SIG. The assigned object ID

values for the OIW and for each SIG are in Appendix A. The assignment

of values below each SIG in the object identifier tree is the

responsibility of that SIG.

6.3 REGISTRATION PROCEDURES FOR OBJECT IDENTIFIERS

This section specifies the responsibilities of each SIG and the

procedures to be followed for the registration of information objects,

and submission to the OIW Plenary.

When an OIW SIG defines an information object the SIG shall register

the object identifier. The registered value shall be incorporated

into the appropriate OIW Agreements Document as a result of a positive

ballot response of the OIW Plenary,

6.3.1 SIG Registration Authorization

An OIW SIG is authorized by its charter and the scope of its work

to submit a registration request to the OIW Plenary.

6.3.2 SIG Registration Authority Function and Duties

6-4
March 1990 (Stable)

The SIG Chair is responsible for the assignment, recording and

maintenance of the SIG's registered objects. The SIG Chair may

appoint a specific person to carry out the SIG duties and

responsibilities

.

6.3.3 Requirements for Information Object Registration

6.3.3.1 Assignment of Object Identifier Component Values

Each SIG shall register an object identifier component value

for each object's technical definition. The

NameAndNumberForm of the Obj IdComponent specified in ISO

8824/CCITT X.208 is used exclusively. This form comprises

an ASN.l identifier and, significantly, a NumberForm.

It is suggested that the SIG assign a monotonically

increasing integer to the NumberForm at any given level. To

the significant root the SIG shall add a assigned object

identifier component value that shall be unique. An example

of an object identifier created by the RASIG is shown as follows

{ iso(l)identified-organization(3) oiw(14) rasig(13) example(O)}

Teehnieal -Definitions

Example -PrintableStrtng h h="-

'^This -is -an -example .-"

Here rasig is the SIG identifier and 13 is the NumberForm

assigned by the OIW Registration Authority (see Appendix A)

;

example is the identifier and 0 is the NumberForm assigned

by the RASIG.

6.3.3.2 Proposal of Object and Identifier to Plenary

Registration of an object identifier and its definition is

proposed by inclusion of the object identifier and its

definition in the OIW "Working Implementation Agreements"

document

.

6-5
March 1990 (Stable)

6.3.3.3 Completion of Registration Procedure

Registration of an object identifier and its definition is

completed upon Plenary vote to move "Working

Implementation Agreements" text which contains the object

identifier and its definition of to the "Stable

Implementation Agreements" document.

• i 6.3.3.4 Changes and Revisions to the Information Object

Registration

Neither the technical definition nor the object identifier

shall be changed or modified after registration i.e., after

the definitions and their identifiers have been voted into

the "Stable Implementation Agreements" document.

6.3.4 Register Index

Each SIG shall maintain an index of object identifiers that point

to the technical definitions of the respective objects in the OIW

Agreements Document. The index shall appear in the appropriate

chapter annexes of the OIW Agreements Document.

Index entry example:

Object Identifier Reference

iso identified-organization Chapter 6.3.3.1

oiw(14) rasig(13) example(O)

6-6
December '89

6.4 APPENDIX A: ASSIGNMENTS TO WORKSHOP ORGANIZATIONS

X vJ-Cli L. X X. XO I.

W X w 1 L ^ri.oox^iicu L.U \-/xw '-'y ISO 6523 RA")

llsig 1 (Assigned to SIG by OIW)

nmsig 2 secsig 3 tpsig 4

ftarns ig 5

mhsig 6

dssig 7 ulsig 8

rdasig 9

mmssig 10

odasig 11

vtsig 12

rasig 13

6-7
December '89

6.5 APPENDIX B: STATUS OF 1987 AND 1988 AD-HOC OBJECT IDENTIFIERS

In the 1987 and 1988 versions of the Stable Implementation Agreements,

a number of OlW-specified information objects are assigned object

identifiers

.

OSI requires names and addresses, e.g., object identifiers, be

globally unambiguous. This chapter specifies object identifier

component values which are globally unambiguous. Other chapters in

this document specify the correct object identifiers to be used when

referencing OlW-specified information objects.

The use of the 1987 and 1988 OlW-specified object identifiers is

deprecated. Newly defined objects shall use the new OIW Identifier.

6-8
June 1990 Stable

CCITT 1984 X.400 BASED MESSAGE HANDLING SYSTEM

Note: The classification schema used in the chapter (see table

7.7) pre-dated TR 10,000 and was the basis of extensive

harmonization, as such: No attempt will be made to align

this chapter with TR 10,000.

7.1 INTRODUCTION

This is an implementation agreement developed by the Implementor '

s

Workshop sponsored by the U.S. National Institute of Standards and

Technology to promote the useful exchange of data between devices

manufactured by different vendors. This agreement is based on, and

employs protocols developed in accord with, the OSI Reference Model.

While this agreement introduces no new protocols, it eliminates

ambiguities in interpretations.

This is an implementation agreement for a Message Handling System

(MHS) based on the X.400-series of Recommendations (1984) and Version

5 of the X.400 Series Implementor ' s Guide from the CCITT. It is

recommended that product vendors consult later versions of this guide.

Figure 7.1 displays the layered structure of this agreement.

This agreement can be used over any Transport protocol class. In

particular, this MHS agreement can be used over the Transport protocol

class 0 used over CCITT X.25, described in section 5.2 of this

document. In addition, this MHS agreement can be used over the

Transport profiles used in support of MAP (Manufacturing Automation

Protocol) or TOP (Technical and Office Protocols). Note that the MAP

or TOP environment must support the reduced Basic Activity Subset

(BAS) as defined in X.410.

The UAs and MTAs require access to directory and routing services. A

Directory Service is to be provided for each (vendor-specific) domain.

Except insofar as they must be capable of providing addressing and

routing described hereunder, these services and associated protocols

are not described by this agreement.

7-1
June 1990 Stable

User Agent Layer CCITT X.420

Message Transfer Agent Layer CCITT X.411

Reliable Transfer Service Layer CCITT X.410

Presentation Layer CCITT X.410 Sec. 4.2

Session Layer See section 5.9

Figure 7.1. The layered structure of this implementation agreement.

7 . 2 SCOPE

This agreement applies to Private Management Domains (PRMDs) and

Administration Management Domains (ADMDs) . Four boundary interfaces

are specified:

(A) PRMD to PRMD,

(B) PRMD to ADMD,

(C) ADMD to ADMD, and

i*:- (D) MTA to MTA (within a PRMD, e.g., for MTAs from different

. : vendors .

)

In case A, the PRMDs do not make use of MHS services provided by an

ADMD. In cases B and C, UAs associated with an ADMD can be the source

or destination for messages. Furthermore, in cases A and B, a PRMD

can serve as a relay between MDs , and in cases B and C an ADMD can

serve as a relay between MDs. Figure 7.2 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 at each interface shown in figure 7.2. Provision

for the use of the remaining services defined in the X.400 Series of

Recommendations is outside the scope of this document.

With the exception of intra domain connections, this agreement does

not cover message exchange between communicating entities within a
June 1990 Stable

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 without use of bilateral

agreements

.

PRMD = Private Management Domain

ADMD = Administration Management Domain

PRMD

MTA A

---D

MTA B

I A

PRMD

PRMD

B

ADMD

C

ADMD

Figure 7.2. This agreement applies to the interface between: (A)

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

(D) MTA and MTA.

7.3 STATUS

This version of the X.400 based Message Handling System implementation

agreements was completed on December 16, 1988. No further

enhancements will be made to this version. See the next

section- -Errata.

7.4 ERRATA

Defect report material may be in this section, including implementor

agreement versions to which it applies.

7.5 PRMD to PRMD

7.5.1 Introduction

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

connection (interface A in fig. 7.2) of two PRMDs . "Direct" means

that no ADMD or relaying PRMD provides MHS services to facilitate

message interchange. "Direct" does not exclude those instances for

which Administrations happen to be ADMDs but are not providing X.400
June 1990 Stable

services, that is, they are used only to provide lower layer services

such as X.25. Figure 7.3 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.

Private Domain X

—

UA <

MTA <

/ \

the

^remainder

Domain X

NETWORK

P2

PI

Private Domain Y

> UA <—

^> MTA

/ \

iiiiithe iiiiremainder

Domain Y

NETWORK

of

Figure 7.3. Interconnection of private domains.

7.5.2 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

.

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

7-4
December '89

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.

7.5.2.1.1 Support (S)

a) Support means:

o The service provider makes the service element

available to the service user, and

o The service user gives adequate support to the

MHS to invoke the service element or makes

information associated with the service element

available

.

b) Support for Origination means that:

o The service provider makes the service element

available to the service user for invocation,

and

o The service user gives adequate support to the

end user of the MHS to invoke the service

element

.

c) Support for Reception means that:

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

7-5
December '89

7.5.2. 1 .2 Non Support (N)

This means that the service provider is not required to

make the service element available to the service user. However, the service provider should not regard the

occurrence of the corresponding protocol elements as an error and should be able to relay such elements.

Implementations making a profile available should

indicate deviations (additions or deletions) with

respect to the requirement in the profile.

7.5.2.1.3 Not Used (N/U)

This means that although the Recommendation allows this

service element, this profile does not use it.

7.5.2.1.4 Not Applicable (N/A)

This means that this service element does not apply in

this particular case (for originator or recipient)

.

7.5.2.2 Summary of Supported Services

a) Within a PRMD, a User Agent must support all P2 BASIC

IPM Services (X.400) and all P2 ESSENTIAL IPM Optional

user facilities (X.401) subject to the qualifiers listed

in Appendix 7A.

b) 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 7A.

c) No support is required of the additional optional user

facilities of X.401.

7.5.2.3 MT Service Elements and Optional User Facilities

Tables 10.1 through 10.3 show the message transfer (MT)

service elements and optional user facilities.

7-6
December '89

Table 7.1. Basic MT service elements

Support (S) or Service Elements Non-support (N)

Access Management N/U-*- Content Type Indication S

Converted Indication S

Delivery Time Stamp Indication S

Message Identification S

Non-delivery Notification S

Original Encoded Information Types Indication S Registered Encoded Information Types N/U^

Submission Time Stamp Indication S

' Not applicable to co-resident UA and MTA.

Table 7.2. MT optional user facilities provided to the UA-selectable on a per-message basis

Support (S) or MT Optional User Facilities Categorization Non- support (N)

Alternate Recipient Allowed E S

Conversion Prohibition E S

Deferred Delivery E N

Deferred Delivery Cancellation E N

Delivery Notification E S

Disclosure of Other Recipients E N

Explicit Conversion A N

Grade of Delivery Selection E S

Multi-destination Delivery E S

Prevention of Non-delivery Notification A N

Probe E

Return of Contents A N

1-1
December '89

Table 7.3. MT optional user facilities provided to the UA agreed for any

contractual period of time

Support (S) or MT Optional User Facilities Categorization Non- Support (N)

Alternate Recipient Assignment A N

Hold for Delivery A N/U

Implicit Conversion A N

E: Essential optional user facility.

A: Additional optional user facility.

^ A local facility subject to qualifiers in Appendix 7A.

^ Support not required for an originating MT user; support must be provided

for recipient MT users.

^ Subject to qualifiers in Appendix 7A.

7.5.2.4 IPM Service Elements and Optional User Facilities

Tables 7.4 through 10.5 show the IPM service elements and

optional user facilities.

-•I

7-8
December ' 89

Table 7.4. Basic IPM service /"\ 1 /-\ rv\ ir\ i~ ^

Origination 1? on t* 1 f\r\ IXC- ^C7Li i^X^ll Service Elements by UAs

Access Management N/U^

Content Type Indication 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/A^

Submission Time Stamp Indication S S

IP-message Identification S S

Typed Body S S

Does not apply to co-resident UA and MTA.

Table 7.5. IPM optional facilities agreed for a contractual period of time

Support (S) or Service Elements Categorization Non-Support (N)

Alternate Recipient Assignment A N

Hold for Delivery A N

Implicit Conversion A N

7-9
December '89

Table 7.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)^ 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 7A.

7-10
December '89

7.5.3 X.400 Protocol Definitions

This section reflects the agreements of the NIST/OSI Workshop

regarding PI and P2 protocol elements.

7.5.3.1 Protocol Classification

The protocol classifications are defined below in table 7.7:

Table 7.7. Protocol Classifications

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.

7-11
December '89

7.5.3.2 General Statements on Pragmatic Constraints

a) Where a protocol element is defined as a choice of

Numeric String and Printable String (i.e.,

Administration Domain Name and Private Domain

Identifier) , then a numeric value encoded as a printable

string is equivalent to the same value encoded as a numeric string. This does not apply to the Country Name

protocol element.

b) 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.

c) 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.

d) 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.

7.5.3.3 MPDU Size

The following agreements govern the size of MPDUs:

o All MTAEs must support at least one MPDU of at least two

megabyte , and

o The size of the largest MPDU supported by a UAE is a local matter.

7.5.3.4 PI Protocol Elements

7.5.3.4.1 PI Envelope Protocol Elements

Table 7.8 contains Protocol Elements and their classes.

7-12
December '89

Table 7.8. PI protocol elements

Element Class Restrictions and Comments

MPDU

UserMPDU G

Del 1ve ryRepo rtMPDU G

ProbeMPDU H

UserMDPU

UMPDUEnvelope M

UMPDUContent M

UMPDUEnvelope

MPDUIdentifier M

originator ORname M

originalEncodedlnformationTypes G

If this field is absent, then the

Encoded Information Type is

"unspecified.

ContentTjrpe M

H

Priority G

PerMessageFlag G Maximum length = 2 octets.

deferredDe livery 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

MPDIITdpnti f1 er GlobalDomainldentifier M

lASString M Maximum length = 32 characters,

graphical subset only. Refer to

T.50 for clarification of graphical

PerMessageFlag subset

.

discloseRecipients H

conversionProhibited G

alternateRecipientAl lowed H

contentReturnRequest X

(Continued on next page.)

7-13
December '89

Table 7.8. PI protocol elements, Continued

Element Class Restrictions and Comments

PerDomainBilateralInf

o

CountryName M Maximum length = 3 characters.

AdrainistrationDomainName M Maximum length = 16 characters.

Bilateral Info M Maximum depth = 8 ; maximum

length = 1024 octets

(including encoding).

Recipientinf

o

recipient M

Extens ionldentifier M Maximum value = 32K - 1 (32767).

perRecip lent Flag M Maximum length = 2 octets.

1 1 -1_ _L V . j_ I— \j V i I V ^ O ^ V> 1

1

Y

perRecip ientFlag

ResponsibilityFlag M

ReportReques

t

M

II\J %J p tRX, LVV^pnoT VJ \J J_ t"RJ- V pV-^ niip vJ wA •w' >J<> t^ M

Tracelnformat i on RpfpTpnf p 'sboul d bp madp to

Version 5 of the X.400 Implementor's Guide for information

GlobalDomainldentifier M related to Trace sequencing.

DomainSuppliedInf

o

M

DomainSuppliedInf

o

arrival M

deferred X

action M

0=relayed (value) G

l=rerouted (value) H Rerouting is not required.

converted H

previous H

ORNamp cpr»t-ion 7 S 3 S

EncodedlnformationTypes

bit string

(

M Delivery can only occur if match

is made with Registered Encoded

Information Types. Individual

vendors may impose limits.

Maximum length = 4 octets.

G3NonBasicParameters X

TeletexNonBasicParameters X

PresentationCapabilities X

(Continued on next page.)

7-14
December '89

Table 7.8. PI protocol elements, Continued

Element Class Restrictions and Comments

Del iveryRepo rtMPDU

DeliveryReportEnvelope M

De 1 ivervReDortContpnt' M

DeliveryReportEnvelope

report M

originator M

Traceinformat ion M

De 1 iveryReportContent

original M

intermediate G See comment at end of table.

UAContentID G

ReportedRecipientlnfo M Maximum number = 32K ~ 1 occurrences

.

returned H Can only be issued if specifically

requested in the originating

message

.

billinginformat ion X Maximum depth = 8 ; maximum

length = 1024 octets (including

encoding)

.

ReportedRecipientlnfo

recipient M

Extensions Identifier M

PerRecip lentFlag M

Las tTrace Information M

intendedRecipient H

Supplementaryinformation VA Maximum length = 64 characters.

Value is pending verification by

the CCITT SG VIII or XI.

Las tTraceInformat ion

arrival M

converted G

Report M

(Continued on next page.

7-15
December ' 89

Table 7.8. Pi protocol elements, continued

Element Class Restrictions and Comments

Report

Deliveredlnfo G Generated if delivery is reported.

Nonde 1 iveredinf

o

G Generated if failure to deliver

is reported.

UG J.iVcircOJ.IlZO ae 1 ivery M

typeofUA K This element must be generated with

a PRIVATE value by PRMDs

.

NonDe 1 iveredinf

o

ReasonCode M

DiagnosticCode H Whenever possible, use a meaningful

diagnostic code.

ProbeEnvelope

probe M

originator M

ContentType sfl UAContentID H

• Maximum length = 16 characters.

original If this field is absent, then the

Encoded Information Type is

"unspecified.

Tracelnformation M

PerMessageFlag G

contentLength H

PerDomainBilaterallnfo X

Recipientlnfo M Maximum number = 32K - 1 occurrences

.

GlobalDoraainldentifier

CountryName M Maximum length = 3 characters.

AdministrationDomainName (4) M Maximum length - 16 characters or digits

.

PrivateDomainldentifier R Maximum length = 16 characters or digits. This element must be

generated by PRMDs

.

End of Definitions

7-16
December '89

Notes on table 7.8

Coinment on intermediate Tracelnformation in the

DeliveryReportContent in table 7.8: Audit and confirmed reports

should not be requested by other than the originating domain for

two reasons. First, the return path of the report may be

different from the path taken by the original message, and it may

exclude the domain that added the request for audit and confirmed

to the message. Second, if the return path is different from the

path of the original message, the originating domain would

receive intermediate trace information that it did not request.

7.5.3.5 ORName Protocol Elements

Only form 1 variant 1 0/R names are supported.

Table 7.9 contains ORName protocol elements.

These agreements interpret 1984 X.400 section 3.4 to mean

that the attributes in the ORName in the MPDU must identify

exactly one UA, and that all the values for the attributes

specified in the ORName must be identical to the values of

the corresponding attributes associated with the recipient

UA. Underspecifled names that are unique are deliverable.

Overspecifled ORNames, ORNames with mismatching fields, and

ambiguous names are to be non- delivered or sent to the

alternate recipient as appropriate.

7-17
December '89

Table 7.9. ORName protocol elements

J-jJ-dlLdlL. Place Rtvco oc ^UXT" TXL- t"L.X(Jl1o 1 r^n c ctilU anH (^rMnmont'o V^UUUIlc:; il L.

o

nPNTamo

C t~ o "n 'a "V" A "f" T V\i 1 ^ A T T ^ M

T^r^m^i 1 nT^^ "F T H A t" t"T" 1 Vii 1 1" ^ T i ct" £i. Y

Qo t-uaiitiaL anH a Y"H A f- f- VT Kn t-oT ic-h ^^ ^ uj\c. ul x du. J-ij. s l. \ ^ j UUIl L L yIN cilllc PI\. A o ^ o 1 nA 1 n Y /111 M a V n mi i vn r\S UcXXllcU. XII A.M-XX , ila-XXIItUJU j.engcn — -> cnaracLeLS.

rtomiuis tratxonuomaiiuName P Maximum length = 16 characters

or digits.

X12lAddress X Maximum length = 15 digits.

Tprmi 1 TD " . X i. Ill J- i Id X X 1^ Y 1 IdA. XllIUJIl XCilE.L.il ~ £-'-r 1 id X CL^ L. w X o . ri\j Msj V T mi im loncTt"n — \ r\ r*\\ a a r* f' ^ y c ridAxiiicuii xcii^L-ii — xu ciidXdL'Ccxo.

OrganizationName (2) G Maximum length = 64 characters.

UniqueUAIdentifier X Maximum length = 32 digits.

rcL sonaxiName pVJ naximum i.engcn ot vaj.ues ol sud

exemenus — dm- ciiaLac lcits . Note: The possibility that this

value may be reduced to 40

cnaracuers is lor lurtner

CI ria-Xxmuni xcriguii — dl. dicixcicucxb pci

C/C IXX X C Ll(^ C . t\ UldAXUlLlUl (J J_ i.ULli- ^ 1 1 o o o o Y~ o all mt.t o r\

DomainDefinedAttributeList (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.

generationQualifier G Maximum length = 3 characters.

(Continued on next page.)

7-18
December '89

Table 7.9. 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 descending sequence, from the most

significant <Organizational Unit> (highest in organization

hierarchy) to the least significant. Only those specified

should be sent. (That is, an unspecified <Organizational Unit>

should not be sent along as a field of [null] content, nor zero length , etc .

)

4. This attribute shall contain one space in all ORNames of messages

originated in a PRMD that is not connected to an ADMD, and in

ORNames of recipients reachable only through a PRMD; otherwise,

this attribute shall contain an appropriate ADMD name.

5. Some existing systems which will be accessed via an X.400 service

(whether directly connected using X.400 protocols or otherwise)

may require the provision of addressing attributes which are not

adequately supported by Standard Attributes as defined in these

Agreements. In such cases, Domain Defined Attributes are an acceptable means of carrying additional addressing information.

Failure to support the specification and relaying of DDAs may

prevent successful interworking with such existing systems until

such time as all systems are capable of relaying and delivery

using only the Standard Attribute list. Specific recommendations

on the use of DDAs for particular applications are in the

Recommended Practices section 7.12, Appendix B.

7.5.3.6 P2 Protocol Profile (Based on fX.420n

Tables 7.10 and 7.11 classify the support for the P2

protocol elements required by this profile. The tables

give restrictions and comments in addition to X.420.

Restriction on length is one of the types of restrictions.

7-19
December '89

The reaction of implementations to a violation of this

restriction is not defined by this Profile.

.1 7.5.3.6.1 P2 Protocol - Heading

Table 7.10 below specifies the support for protocol

elements in P2 Headings.

Table 7.10. 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 R

authorizingUsers H

primaryRecipients G At least one of primaryRecipients,

copyRecipients G copyRecipients, or blindCopyRecipients must be

blindCopyRecipients H present

.

inReplyTo G

obsoletes H

crossReferences H

subject G Maximum length = 128 T.61

characters (256 octets); the ability

to generate the maximum size

subject is not required.

expiryDate H

replyBy H

replyToUsers H

importance H Appropriate action is for further

s tudy

.

sensitivity H Appropriate action is for further

study.

autoforwarded H

(Continued on next page.)

f

- j' 7-20

1
December '89

Table 7.10, P2 heading protocol elements, continued

Element Class Restrictions and Comments

IPmessageld

ORName H

PrintableString M Maximum length = 64 characters.

ORDescriptor

ORName H Specify the ORName whenever it is

possible. See Appendix 7B.

freeformName H Maximum length = 64 characters,

graphical subset only (128 octets.)

te 1 eplioneNumbe r H Maximum length = 32 characters

.

This allows for punctuation. It

does not take into account possible

future use by ISDN.

Recipient

ORDescriptor M

reportRequest X

replyRequest H

Body No limit on number of BodyParts.

BodyPart G No limit on length of any BodyPart

or the depth of ForwardedlPMessage

BodyParts nested. Classification is

subject to pending CCITT resolution

SR-UAPDU

nonReceipt H

receipt H

reported M

actualRecipient R

intendedRecipient H

converted X

NonReceiptlnformation

reason M

nonReceiptQualifier H

comments H Maximum length = 256 characters.

returned H May only be issued if specifically

requested by originator.

(Continued on next page.)

7-21
December '89

Table 7.10. P2 heading protocol elements, continued

Element Class Restrictions and Comments

ReceiptInformation

receipt M

typeOfReceipt H

Supplementarylnformation X Maximum length = 64 characters

.

Note: This value is pending

verification by the CCITT SG

1, VIII or IX.

End of Definitions

7.5.3.6.2 P2 Protocol - BodyParts

a) All BodyParts with identifiers in the range 0 up to

and including 16K -1 are legal and should be

relayed. BodyPart identifiers corresponding to

X.121 Country Codes should be interpreted as described in Note 2 of figure 7.4.

o Implementations are required to generate and

image lASText.

o Implementations should specify the other

BodyPart types supported.

o If an implementation supports a particular

BodyPart type for reception, it should also be

able to support that BodyPart type for reception

if it is part of a ForwardedlPMessage

.

o For the BodyPart types currently considered,

support for the protocol elements is as indicated in table 7.11.

b) Privately Defined BodyParts

This section describes an interim means for identifying

privately defined BodyParts. This section shall be

replaced in a future version taking into account CCITT

recommendations with equivalent functionality.

7-22
December '89

BodyPart : : = CHOICE {

[0] IMPLICIT lASText,

[1] IMPLICIT TLX,

[234] IMPLICIT UKBodyParts,

[310] IMPLICIT USABodyParts

,

) Where UKBodyParts and USABodyParts are defined as

SEQUENCE {BodyPartNumber, ANY)

BodyPartNumber : := INTEGER

Note 1: In the EncodedlnformationTypes of the Pi Enveiope, the

undefined bit must be set when a message contains a privately defined BodyPart. Each UA that expects such

BodyParts should include undefined in the set of

deliverable EncodedlnformationTypes it registers with the

MTA.

Note 2: All BodyPartNumbers assigned must be interpreted relative

to the BodyPart in which they are used, which is that

tagged with the value [310] for those defined within the

United States. The NIST assigns unique message

BodyPartNumbers for privately defined formats within the

United States.

Note 3: Refer to section 7.12.6 for recommendations regarding the

implementaion of USABodyParts,

Figure 7.4. X.409 Definition of Privately Defined BodyParts.

7-23
December '89

7.5.3.6.3 P2 BodyPart Protocol Elements

Table 7.11. P2 BodyParts

Elements Class Restrictions and Comments

BodyPart

lASText G

TLX X

Voice X

G3Fax X

TIFO X

TTX X

Videotex X

NationallyDe fined X

Encrypted X

ForwardedlPMessage H

SFD X

TIFl X

unidentified X

IA5Text

repertoire H

lASString M For rendition of lASText see Appendix 7C.

TLX For further study by CCITT.

Voice

Set For further study by CCITT,

BitString M

G3Fax

numberOfPages X

PI .G3NonBasicParameters X

SEQUENCE (OF BIT STRING) M

BIT STRING H See Note.

PI . G3NonBasicParameters Support for individual elements is

for further study.

TIFO

T . 73Document M

T . 73ProtocolElement H See Note.

(Continued on next page.)

7-24
December ' 89

Table 7.11. P2 BodyParts , continued

Elements Class Restrictions and Comments

TTX

numberOfPages X

telexCompatible X

PI . TeletexNonBasicParams X

SEQUENCE M

T61S tring H See Note.

PI .TeletexNonBasicParams

graphicCharacterSets X

controlCharacterSets X

pageFormats X

miscTerminalCapabilities X

privateUse X

Videotex

SET For further study by CCITT.

Video texS tring M

NationailyDefined

ANY M

Encrypted

SET For further study by CCITT.

BIT STRING M

ForwardedlPMessage

delivery H

De 1 i veryInformation H

IM-UAPDU M

Deliverylnformation

PI . ContentType M

originator M

original M

PI . Priority G

DeliveryFlags M

otherRecipients H

thisRecipient M

intendedRecipient H

converted X

submission M

(Continued on next page.)

7-25
December '89

Table 7.11. P2 BodyParts , continued

Elements Class Restrictions and Comments

SFD

SFD. Document M

TIFl

T73 Document M

T73 . ProtocolElement H See note

Note: This element is not an addition to the definition of the BodyPart.

It is described here to show that the SEQUENCE may contain zero elements. A Problem Report has been submitted to the CCITT to

clarify whether this is permissible. The NIST/OSI Workshop

will adopt the CCITT decision.

7.5.4 Reliable Transfer Server (RTS^

7.5.4.1 Implementation Strategy

Based on X.410 Clause 3 and X.411 Clause 3.5.

7.5.4.2 RTS option selection

a) 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

.

b) Associations are established by the MTA which has

messages to transfer.

c) Associations are released when they are not needed.

Associations may also be ended prematurely due to

internal problems of the RTS.

d) For both monologue and two way alternate associations,

the initiator keeps the initial turn.

e) 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:

7-26
December '89

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.

f) The 'priority-mechanism' and the ' transfer- time limit' are regarded as local matters.

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

a) One RTS association corresponds to one or more consecutive session connections (not concurrent ones)

.

The first is opened with ConnectionData of type OPEN,

and subsequent ones are opened with type RECOVER.

b) Recovery of a Session connection is only by RTS

initiator.

c) Checkpoint size :

o Checkpointing and No Checkpointing should be

supported. Whenever possible, checkpointing should

be used.

o The minimum checkpointSize is 1 (that is, 1024

octets)

.

d) Window size :

o Minimal value of 1 (if checkpointing is supported)

.

o WindowSize = 1 means: After an S-SYNCH-MINOR

request is sent, wait until the confirmation is

received before issuing an S-DATA, S-SYNCH-MINOR, or

S -ACTIVITY- END request.

e) APDUs should not be blocked into one activity.

f) Only one SSDU shall be transferred:

o Between two adjacent minor synch points.

o Between minor synch points and adjacent

S -ACTIVITY- START and S -ACTIVITY- END requests.

7-27
December '89

o Between S -ACTIVITY- START and S -ACTIVITY- END without

checkpoints

.

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.

A two-way alternate association is as described in

X.410.

In the UserData parameter of the S-U- ABORT, the

ReflectedParameter will not be used in the

Abortlnformation element.

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.

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 OldSessionConnectionldentifier in

S -ACTIVITY-RESUME must match the value of the

SessionConnectionldentif ier parameter used in the

S-CONNECT of the prior session connection. This

value is also identical to the

SessionConnectionldentifier in the ConnectionData

(in PConnect, in SS-UserData) for the current

session connection.

o This must occur as the first activity of the next

session connection for the same RTS-association. It

7-28
December '89

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.

1) 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.

m) In S -TOKEN- PLEASE, the UserData parameter shall contain

an integer conforming to X.409 which conveys the

priority.

n) The receiving RTS can use the value of the Reason

parameter in the S-U- EXCEPTION-REPORT to suggest to the

sending RTS that it should either interrupt or discard

the current activity. S-U- Exception Reports are handled

as stated in Version 5 of the Implementors Guide pages

12-13, paragraph E-33.

o) In the case of S-P-ABORT, the current activity (if any)

is regarded as interrupted, rather than discarded.

p) Table 7.12 illustrates the legal negotiation

possibilities allowed by X.410 Clause 4.2.1 regarding

checkpoint size and window size.

q) These agreements include the provisions of Version 6 of

the Implementors Guide identical in all respects to

Version 5, except that the following points have been

added to section 3.5:

for section 4.4.1 of X.410;

"If the receiving RTS receives an S-ACTIVITY-DISCARD

indication primitive and has already issued a TRANSFER

indication primitive, it aborts the connection (S-U-ABORT

request) with the "transfer completed" version code."

for section 4.6.2 of X.410

"The "transfer completed (7)" abort reason is used to

indicate to the sending RTS that the receiving RTS could not

discard the activity because it has already completed the

transfer (issued a TRANSFER indication primitive),"

Transfer completed (7) is also added to the table of abort

reasons in this section.

7-29
December '89

Table 7.12. Checkpoint window size of IP

acceptor answer

CS = 0

(or unspecified)

WS unspecified

CS = m

WS = j

(or unspecified)

CS = n

WS = j

(or unspecified)

initiator

proposal

CS = 0

(or unspecified)

WS --= i

(or unspecified)

legal legal legal

CS = k

WS = 1 (or unspecified)

legal legal not allowed

Legend

o CS means CheckpointSize

o WS means Windows ize

o i, j, k, m, 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

substitutefor the unspecified integer.

7.5.4.4 RTS Protocol Limitations

The RTS Protocol Limitations for this profile are listed in

table 7.13.

7-30
December '89

Table 7.13. RTS protocol elements

Element Class Restriction

PConnect M

M Value = 0.

pUserData M

checkpoints ize H

windows ize fl dialogueMode H

ConnectionData M

applicationProtocol G Value = 1. H Value = 8883.

ConnectionData

open G

recover G

open

RTS user data G

recover

SessionConnectionldentifier G

Kio user cxaua mTAName G Maximum length 32 characters

password G Maximum length 64 octets

graphic subset of IA5 only. < null RTS User Data > G Generated if other validation

methods are used.

SessionConnectionldentifier

CallingSSUserReference M Maximum length 64 octets including

encoding = 62 octets of T.61.

CommonReference M

AdditionalReference Information H Maximum length 4 octets including

encoding = 2 octets of T.61.

PAccept G

DataTransferSyntax M Value = 0.

pUserData M

checkpoints ize H

windows ize H

ConnectionData M

(Continued on next page.)

7-31
December '89

Table 7.13. RTS protocol elements, continued

Element Class Restriction

PRefuse

RefuseReason

G

M

SS User Data

(in S- TOKEN -PLEASE)

G See Note

Abortinformation

(in S-U-ABORT)

AbortReason

reflectedParameter

i - ' • G

<'r- H

X Restricted to 8 bits.

End of Definitions

Note: Generated if supplied by the RTS -user. The RTS use may

specify a priority in the TURN-PLEASE primitive, and if so,

it is carried as the SS-User-Data in S- TOKEN -PLEASE.

7.5.5 Use of Session Services

The session requirements and use of session are covered in

section 5 of this document.

7.5.6 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 7C defines rendition of IA5 Text and T61

characters

.

7.6 PRMD to ADMD and ADMD to ADMD

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

7-32
December '89

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 PElMD's

support to its customers through the integrated UAs . These are distinct functional differences. The services provided to the

UAs of an ADMD are independent of the requirement that an ADMD

provide a function for interworking with any type of Management

Domain (MD) . Figure 7.5 illustrates the two roles played by an

ADMD.

This section is presented in the form of deviations from the

agreements applicable to PRMD-to-PRMD (sec. 7.5). Unless

explicitly noted in the remainder of this section, all of the

specifications for PEIMD to PRMD apply to PRMD to ADMD and ADMD to

ADMD.

7-33
December '89

PRMD or ADMD

IPM - UA

<--

< - MTA

-P2-

-Pica)

PRMD or ADMD PRMD or ADMD

IPM - UA <-- -> IPM - UA

MTA MTA

PI PI

(b)

Figure 7.5. An ADMD may (b) or may not (a) serve as a relay.

7.6.2 Additional ADMD Functionality

The following defines the additional ADMD specific functionality

required over and above that specified in the PRMD section.

7.6.2.1 Relay Responsibilities of an ADMD

ADMDs will relay all content types (not just P2) unchanged

in the absence of a request for conversion.

7-34
December '89

7.6.2.2 PI Protocol Classification Changes

Table 7.14 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)

.

Table 7.14. PI Protocol Classification Changes for a Delivering ADMD

Protocol Elements Class

Deliveredlnfo

typeOfUA H

ReportedRecipientlnfo

Supplementarylnformation H See Note 1

GlobalDomainldentifier

PrivateDomainldentifier H

For relaying Administration domains, the classifications are all "X"

For originating Administration domains, these are all

"NOT APPLICABLE."

Note 1: Domains providing access to TELEX/TELETEX recipients, whether

directly or indirectly as a result of bilateral agreements

between domains, must ensure that this information, when

present, is accessible by the recipient of the delivery report.

7.6.2.3 0/R Names

0/R Names shall consist of:

o CountryName

,

o AdministrationDomainName

.

as well as one of the following:

o PrivateDomainName

,

7-35
December ' 89

o PersonalName

,

o OrganizationName

,

o OrganizationalUnit

,

o UniqueUAIdentifier

o X12lAddress.

and permits the optional inclusion of a

o DomainDefinedAttributeList

.

Note: The destination PrivateDomainName or OrganizationName must be present if destined for a

PEiMD. The ADMD relaying the message to that

destination PRMD requires this element.

7. 6.2.4 PI ADMD Name

Management Domains (MDs) must specify in the ADMD name field

of the 0/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)

,

7.6.3 Interworking with Integrated UAs

If the message originates at a UA owned by an ADMD, or is

delivered to such a UA, the 0/R Name follows the same Form 1 Variant 1 constraints as the base specifications; except that the

ADMD name is the name of the ADMD that owns the UA and instead of

supplying a PRMD Name, one (or more) of the following must be

provided:

o OrganizationName,

o OrganizationalUnit,

o PersonalName.

and may optionally include a

o DomainDefinedAttributeList

.

7-36
December '89

7.6.4 Differences with Other Profiles

7.6.4.1 TTC Profile

There are no outstanding issues regarding interworking

between TTC -conformant systems and NIST-conformant systems

with the exception of the number of recipients and the

supported MPDU sizes. The Extensionldentifier field may

contain a maximiam value of 32K-1; however, according to the

current TTC profile, if a message with more than 256

recipients is received, some TTC -conformant domain may

generate a nondelivery notification. This also applies to

the ReportedRecipientlnfo in a delivery report. Further, a TTC MTA is required to handle an MPDU size of at least 32KB.

The NIST required MPDU size is 2MB as covered in section

7.5.3.3. Other differences are shown in Appendix E. TTC

is currently based on Version 4 of the Implementor ' s Guide.

7.6.4.2 CEPT Profile

See Appendix 7E.

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

It should be noted that a single PRMD that is connected to more

than one ADMD can be represented by more than one combination of

7-37
December '89

country-name, ADMD-name, and PRMD name. For example, it may

occur that the PRMD-name for a particular PRMD may take different

values, depending on the ADMD-name. Implementors should be aware of the consequences of these possibilities on routing.

7.6.6 Connection of an ADMD to a Routing PRMD

It is possible for a collection of interconnected private domains

to establish one domain as the "gateway" to an ADMD, and hence to

the world.

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 Traceinformation

may contain more than one element.

The X.400 Recommendations specify that an ADMD should not attempt

to relay a message destined for another ADMD through a PRMD, thus an ADMD should ensure that messages destined for another ADMD are not relayed through a PRMD. It should be noted, however, that a relaying PRMD will relay any such message it receives.

7.6.7 Management Domain Names

o All Management Domain Names (both Private and

Administration) shall be unique within the U.S.

o A central naming authority shall be established to register

domain names

.

7.6.8 Envelope Validation Errors

For validation errors, a non-delivery notice shall be generated

(if possible) with reason code of ' unableToTransfer ' and

diagnostic code of ' invalidParameters ' (unless specified

otherwise)

.

ADMDs will validate Pi Envelopes in the following areas:

a) The X.409 syntax of all elements should be checked.

b) The pragmatic constraint limits (lengths of fields and

number of occurrences of fields) should be checked.

7-38
December '89

Semantic validation of the following elements should be

done

o originator 0/R Name

,

o recipient 0/R Name in the Recipientinfo

,

o Priority.

Only recipient Names with the responsibility flag set should

be validated. The validation of 0/R names is defined in

7.8.3.3; the validation of priority is defined in 7.8.3.7.1.

MPDU Identifier Validation

o Validation of the GlobalDomainldentifier component of

the MPDU Identifier is performed upon reception of a message (i.e., as a result of a TEIANSFER. Indication) .

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

o Additional validation of the GlobalDomainldentifier 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.

o A request will be generated to the CCITT for a more meaningful diagnostic code (such as

' InconsistentMPDUIdentifier ' )

.

9 Quality of Service

7.6.9.1 Domain Availability

7.6.9.1.1 ADMD Availability

The goal is to provide 24 hour per day availability.

Note that there will be periods of time when an ADMD may

be unavailable due to maintenance windows in its

supporting network or in an MTA within the domain.

7-39
December '89

7.6.9.1.2 PRMD Availability

Although the goal of PRMD availability is also 24 hours

per day, business reasons are likely to dictate some different level of availability. ADMDs shall require a profile from the PRMD that indicates its schedule of

regular availability to the ADMD.

7.6.9.2 Delivery Times

In the absence of standardized quality of service

parameters, the following are agreed to. When standardized

parameters from CCITT Study Group I become available, they

shall be adopted.

7-40
December ' 89

a) In table 7.15 the following delivery time targets are established:

Table 7.15. Delivery Time Targets

Delivery Class 95% Delivered Before

Urgent 3/4 hour

Normal 4 hours

Non-Urgent 24 hours

b) The interval(s) between retries and the number of retry

attempts that an ADMD uses in attempting delivery to a PRMD or integrated UA, will be locally determined domain

parameters. However, the total elapsed times after

which delivery attempts will be stopped are shown in

table 7.16. This implies that, after these times, a Non-Delivery Notice will be generated.

An Administration shall continue to attempt delivery

until the forced nondelivery time, even if the recipient

domain has scheduled an unavailability window.

Table 7.16. Forced Nondelivery Times

Delivery Class NonDelivery Forced After

Urgent 4 hours

Normal 24 hours

Non-Urgent 36 hours

Note: Both tables apply to the period between acceptance by

the originating MTA in the originating Administration

domain to the time of delivery in the destination

Administration domain. Transit time within PRMDs is NOT

included in the above times.

7.6.10 Rill ing Information

a) All aspects relating to billing, charging, tariffs,

settlement, and in particular to the use of the

billinglnformation field in the delivery report, is subject

7-41
December '89

to bilateral agreement, and shall not be addressed in these

implementation agreements.

b) No ADMD shall require a PRMD to supply or process billing

information.

7.6.11 Transparency

a) No PI extensions, other than the MOTIS extensions are to

be allowed (Reference A/3211). Should an ADMD receive a message containing PI extensions, it shall generate a non-delivery notice (if possible) with reason code of

unableToTransfer and diagnostic code of

invalidParameters

.

If MOTIS elements are present, a relaying MTA can optionally:

o Relay the message. If the MTA does relay, it must not

drop any of the protocol elements.

o Non-Deliver the message.

A receiving MTA can optionally:

o Deliver the message

o Non-Deliver the message.

b) The CCITT has been requested to establish a more meaningful

diagnostic code (such as protocolError) for this occurrence.

Such a code has now been provided in the Implementors Guide.

c) P2 extensions shall be relayed transparently by ADMDs

.

7.6.12 RTS Password Management

RTS password management shall be a local matter. This includes:

o password length

o frequency of changes

o exchange of passwords with communicating partners

o loading passwords ( i.e., the timing of password changes

with respect to active associations)

.

7-42
December '89

7.6.13 For Further Study

Issues requiring further study are:

o

o Intra-Domain Routing

Multi-Vendor Domains

7.7 INTER and INTRA PRMD CONNECTIONS

7.7.1 Introduction

This section is limited in scope to issues arising from the

indirect connection of a PRMD to another PRMD or to an ADMD, and

to the interconnection of MTAs to form inter-PRMD connections.

Indirect means that the connection is made via a relaying PRMD.

The X.400 Recommendations describe the way that a PRMD connects

to a ADMD and the way that an ADMD connects to another ADMD. The

Recommendations do not, however, describe the way that a PRMD

connects indirectly to an ADMD or another PRMD, nor do they

describe the way that MTAs are connected within a PRMD. These

configurations (shown in figs. 7.6 and 7.7) are useful, for

example, in connecting equipment from different vendors at a single customer site.

The PI protocol and its related services for both inter and intra

PRMD connections are addressed in this section. In addition, a method for routing within a PRMD is given. It is recognized that

uniform methods for Administration, maintenance, and quality of

service should be developed for such configurations, and this

work is for further study.

This section describes the minimum that must be provided in order

to implement a relaying PRMD and a MTA within a PRMD.

This section is presented in the form of deviations from

agreements applicable to PRMD to PRMD connection (sec. 7.5).

That is, unless specifically noted in the remainder of this

section, the agreements in section 7.5 apply to both relaying

PRMDs and MTAs within a PRMD.

It should be noted that the comments regarding ORNames in section

7.6.5 also apply to this section.

7-43
December '89

7.7.2 The Relaying PRMD

A PRMD that has the capability of relaying messages to another

PRMD is called a relaying PRMD. A PRMD implementation need not

claim to be a relaying PRMD. A PRMD implementation which does

claim to be a relaying PRMD must follow the implementation

agreements in this section.

7.7.2.1 Relay Responsibilities of a PRMD

The responsibilities of a relaying PRMD are the same as those of an ADMD (as specified in sees. 7.6.8 and 7.6.2.1).

In addition, the PRMD will simply deliver messages routed to

it from an ADMD, even if this results in routing a message

from the ADMD to the PRMD to another ADMD,

7.7.2.2 Interaction with an ADMD

In order for an ADMD to route a message to ADMD A via ADMD

B, it must know that A is reachable through B. Similarly,

in order for any MD to route a message to PRMD A via a relaying PRMD B, it must know that A is reachable through B

(see fig. 7.8).

ADMD

PRMD A PRMD B PRMD C

Relay

Figure 7.6. Relaying PRMD.

7-44
December '89

PRMD

MTA A

MTA B

-

MTA D

MTA C

ADMD

or

PRMD

Figure 7.7. Intra PRMD connections.

Note 1: Section 7.6.6 specifies that ADMDs are not required to

connect to a relaying PRMD, but they are not precluded

from doing so.

Note 2: Tracelnformation may have more than one sequence on submission of a message by a relaying PRMD to an ADMD.

MD D

relay

MD C with

a message

for A

relay

MD B

MD A

Figure 7.8, MD C must know of A to route the message.

7.7.3 Intra PRMD Connections

A PRMD is composed of MTAs which cooperate to perform the

functions expected of a domain. An MTA implementation need not

claim to follow the implementation agreements of this section.

7.7.3.1 Relay Responsibilities of an MTA

The relaying responsibilities of an MTA are the same as those of an ADMD (as specified in sees. 7.6.8 and 7.6.2.1)

with one exception: loop suppression within the domain

is done using the MOTIS InternalTracelnfo protocol

element. The MTA must validate the InternalTracelnfo (see

7-45
December '89

sec. 7.8.3.5 for details on validation). In addition, the

PRMD will simply deliver messages routed to it from an

ADMD, even if this results in routing a message from the

ADMD to the PRMD to another ADMD (please see sec. 7.6.6).

7.7.3.2 Loop Suppression within a PRMD

a) The only mechanism defined in the X.400 Recommendations

for suppressing loops is Traceinformation, which is

added on a per domain basis to detect and suppress loops

among domains. Loops among MTAs within a domain need to

be detected and suppressed. This implies that each MTA

must add trace information that is meaningful within the

domain. The MOTIS solution of adding InternalTracelnfo

to the PI Envelope of a message was adopted. The

definition of InternalTracelnfo is given in figure 7.9.

The InternalTracelnfo is added by each MTA within a PRMD

to handle a message, and it is examined in the same way

as Traceinformation to detect and suppress loops.

InternalTracelnfo : := [APPLICATION 30]

IMPLICIT SEQUENCE OF

SEQUENCE { MTAName

,

MTASuppliedlnfo )

MTAName : := PrintableString

Figure 7.9. Definition of InternalTracelnfo.

If the MTAName and password of X.411 are used for

validation, then it is recommended that the MTAName

used for validation also be used in the

InternalTracelnfo. However, there is a complication: in

X.411, MTAName is an lASString, and the MTAname defined

by MOTIS is a PrintableString. Efforts will be made to

change the MOTIS definition from PrintableString to

IA5String.

b) Three actions are defined in MTASuppliedlnfo: relayed,

rerouted, and recipientReassignment as shown in figure

7.10. The recipientReassignment action is not supported

in these agreements. The ability to generate it is not

required, and if it is present on an incoming message,

the action field will be ignored.

7-46
December '89

MTASuppliedlnfo : := SET { arrival [0] IMPLICIT Time,

deferred [1] IMPLICIT Time OPTIONAL,

action [2] IMPLICIT INTEGER

{ relayed(O) , rerouted(l), recipientReassignment (2) } previous MTAName OPTIONAL )

Figure 7.10. Defined Actions in MTASuppliedlnfo.

7.7.3.3 Routing Within a PRMD

a) Routing within a PRMD is complicated by the lack of a directory standard. In particular, it constrains

intra-domain routing decisions to be based on some combination of the intra-domain attributes of the 0/R

Name, Organization Name Organizational Units, and

Personal Name. In order to enhance interworking and to

reduce the difficulty of configuring intra-domain

connections, it is useful to restrict the ways in which

these may be used in making routing decisions.

b) However, it is recognized that vendors may wish to

provide MTAs with varying degrees of routing capability

within a PRMD as a temporary expedient until appropriate

standards for automated construction of directories and

routing tables are available. This section assigns

class numbers to certain levels of routing capability

and discusses the consequences of using MTAs which fall

into each class. The classification scheme will allow

some diversity in allocating O/R Name space and in

configuring intra-domain routes.

c) When other methods are recommended by standards bodies,

the classification scheme described here will become

obsolete. Large-scale, multi-vendor PElMDs may not be

practical in the absence of standardized methods.

7.7.3.3.1 Class Designations

When it is clear that a message is to be delivered

within a domain, the Country Name, ADMD Name, and PRMD

Name have already served their purpose in determining

the next MTA in the route to the recipient. The

remaining fields that might be used on making routing

decisions within the PRMD are the Organization Name,

Organizational Units, and Personal Name.

7-47
December '89

MTAs are classified by their ability to discriminate

between 0/R names when making routing decisions within a PRMD. Conformant MTAs will be classified as shown in

table 7.17.

Table 7.17. Conformant MTA Classifications

Class 1 Class 2 Class 3

Organization Name H H H

SEQUENCE OF Organizational Unit X H H

Personal Name X X H

a) An 'H' means that the MTA must be able to base its

intra-domain routing decisions on the given component of

the O/R Name. In particular, both Class 2 and Class 3

MTAs must be able to discriminate on all the members in

a supplied sequence of OrganizationalUnits . A Class 3 MTA must be able to discriminate on all of the elements

in a PersonalName

.

An 'X' means that the MTA need not have the ability to

discriminate on the given component.

b) There is a hierarchy in support of components. The

ability to discriminate on a given component does

not imply the requirement to do so: e.g., a Class 3

MTA is not required to have tables for every

PersonalName in the domain. Equally, an MTA which

can discriminate on OrganizationalUnits to make

routing decisions need not always use the full

sequence in an O/R Name if a partial sequence

provides enough information.

c) The above classifications only apply to routing

decisions in selecting a next hop within a domain.

All MTAs are entitled to examine the full O/R Name

when identifying their own directly served UAs

.

d) The routing table of a Class 1 MTA will be

relatively small, because intra-domain routing

decisions are based solely on OrganizationName . The

routing table of a Class 2 MTA may be substantially

larger and more complex because of its ability to

discriminate on OrganizationalUnits as well as OrganizationName to make routing decisions. The

routing table of a Class 3 MTA may be larger still.

7-48
December ' 89

because its use of the components of PersonalName in

addition to the other information.

7. 7. 3.3.2 Specification of MTA Classes

If an MTA implementation claims to follow the

implementation agreements, it must be either a Class 1,

Class 2, or a Class 3 MTA. The class of an MTA

implementation should be specified so that PRMD

administrators can choose equipment properly.

7.7.3.3.3 Consequences of Using Certain Classes of

MTAs

Definition: An MTA which accepts submission requests and

furnishes delivery indications to a UA is

said to "directly serve" the UA.

a) The presence in a domain of an MTA acting as a Class

1 or Class 2 MTA imposes administrative restrictions

on the assignment of 0/R Names to UAs and in the

configuration of routes within that domain.

o A Class 1 MTA may directly serve UAs from

several OrganizationNames . However, if a Class 1 MTA directly serves a UA with a given

OrganizationName , no other MTA in the domain may

directly serve a user with the same OrganizationName. This means that if all MTAs

in a domain are Class 1, then all UAs with a given OrganizationName must be assigned to the same MTA.

o A Class 2 MTA may directly serve UAs from any

combination of OrganizationName and sequence of

OrganizationalUnits . However, if a Class 2 MTA

directly serves a UA with a given combination,

no other MTA in the domain may directly serve a user with the same combination. This means that

if all MTAs in a domain are Class 2, then all

UAs with a given OrganizationName and sequence

of OrganizationalUnits must be assigned to the same MTA.

o A domain consisting entirely of Class 3 MTAs is

free of all the above restrictions.

7-49
December ' 89

b) If Class 1 or Class 2 MTAs are used to perform

relaying within a PRMD containing MTAs of other

classes, care must be exercised in determining the

topology of the domain to avoid leaving certain UAs

inacessible from certain MTAs within the domain.

The example below shows one of the configurations

that should be avoided. The example is intended to

stimulate careful examination of the relationship

between network and organizational topologies.

MTA A

serving

Organization X

MTA B

(Class 1)

MTA C

serving

Organization X

Figure 7.11. Example of a configuration to be avoided.

In figure 7.11, B will route all messages for

Organization X to either A or C because B is a Class 1 MTA. The administrator who created this configuration

probably wanted B to route some messages for

Organization X to A, and some to C. However, B does not

have the capability for this because it is only a Class

1 MTA. The configuration in figure 7.11 can be

corrected by replacing B with a Class 2 or Class 3 MTA.

7.7.3.4 Uniqueness of MPDUidentif iers Within a PRMD

When generating an lASString in an MPDUidentif ier , each MTA

in a domain must ensure that the string is unique within the

domain. This shall be done by providing an MTA designator

with a length of 12 octets which is unique within the

domain, to be concatenated to a per message string with

maximum length of 20 octets.

Two pieces of information, the MTA name and MTA designator,

need to be registered within a PRMD to guarantee uniqueness.

This registration facility need not be automated. If the

MTA name is less than or equal to 12 characters, it is

recommended that it also be used as the MTA designator.

7-50
December '89

1 .1 .l\ Service Elements and Optional User Facilities

A PRMD made up of MTAs which support varying sets of service

elements in addition to those required in these agreements may

appear to provide inconsistent service for these elements. For

example, if one MTA supports deferred delivery and another MTA

does not, then deferred delivery can be used by some, but not

all, users in the PRMD. Similarly, if one MTA supports return of

contents and another does not, then a user outside of the PRMD

will receive returned contents for messages sent to one user, but

not for messages sent to another user. Note that this same inconsistency occurs when sending to two PRMDs which support

different additional optional elements.

7.7.5 X.400 Protocol Definitions

This section describes additions and modifications to section

7.5.3 which are required for implementation of a relaying PRMD or an MTA within a PRMD.

7.7.5.1 Protocol Classification

a) The classification scheme given in section 7.5.3.1

applies to elements passing from one PRMD to another.

For both relaying PRMDs, and MTAs in a PRMD, the same classification scheme will be used, but within a PRMD

the classification applies to elements passing from one MTA to another.

b) In addition to the classifications given in section

7.5.3.1, a classification of Prohibited has been used.

PROHIBITED = P

This element shall not be used. Presence of this

element is a protocol violation.

7.7.5.2 PI Protocol Elements

Table 7.18 contains protocol elements and their classes. An

* signifies that the classification of the protocol element

has not changed from table 7.8.

7-51
December '89

Table 7.18. PI Protocol Elements

Element Class Restrictions and Comments

UMPDUEnvelope

MPDUIdentifier M* This field needs to be unique

within a PRMD. See section

7.7.3.4 for the method of

ensuring uniqueness

.

originator M* It is recommended that all

components of the originator's

ORName be included to help ensure

that reports can be returned.

Traceinformation M* The first MTA in the domain to

receive the message adds the

Traceinformation. Subsequent

MTAs can update the

Tracelnformation in the event of

conversion or deferred delivery.

When a message is generated, the

originating MTA adds the

Tracelnformation

.

InternalTracelnfo M/P This element is mandatory for

envelopes transferred between

MTAs within a PRMD, and

prohibited in messages

transferred outside the domain.

Elements are always added to the

end of the sequence. (See Note 1)

InternalTracelnfo

MTAName

M MTANames within a PRMD must be

unique. See section 7.7.3.4 for

the method of assuring uniqueness

Maximum length = 32 characters.

MTASuppliedlnfo M

(Continued on next page.)

7-52
December '89

Table 7.18. PI Protocol Elements, continued

Element Class Restrictions and Comments

MTASuppliedInf

o

arrival M

deferred X This field must be generated by

MTAs which perform deferred

delivery

.

action M See section 7.7.3.2 for

TP Q t"T 1 p t" 1 on c: on vpliipc; of t"b 1 field.

previous X This field must be generated by

MTAs which perform rerouting.

DeliveryReportEnvelope

Tracelnformation M* The first MTA in the domain to

receive the report adds the

Tracelnformation. When a report

is generated, the originating MTA

adds the Tracelnformation.

InternalTracelnfo M/P This field is mandatory for

envelopes transferred between

MTAs within a PRMD , and

prohibited in messages

transferred outside the domain.

(See Note 1)

De 1 iveryReportContent

intermediate InternalTracelnfo P If it were possible to include

this field in the delivery report

content, an audit and confirmed

report could be provided to

detect problems within a PRMD.

Efforts are being made to add

this field to the MOTIS

definition.

Deliveredlnfo

typeOFUA R* It is the responsibility of the

MTA generating the report to

generate this element.

(Continued on next page.)

7-53
December '89

Table 7.18. PI Protocol Elements, continued

Element Class Restrictions and Comments

ProbeEnvelope

Tracelnformation M* The first MTA in the domain to

receive the probe adds the

Tracelnformation. When a probe

is generated, the originating MTA

adds the Tracelnformation.

InternalTracelnfo M/P This field is mandatory for

envelopes transferred between

MTAs within a PRMD, and

prohibited in messages

transferred outside the domain.

(See Note 1)

Note 1: The M classification is only applicable if an implementation is claiming conformance according to

section 7.10.2, point (g) 4th bullet.

7.7.5.3 Reliable Transfer Server CRTS)

In the pUserData of PConnect, the value of

applicationProtocol should be 1. This value was chosen

because the agreements on intra- domain connections are not

strictly PI, nor are they MOTIS. Philosophically, it would

be good to choose a new application protocol identifier for

these agreements, but this introduces too many practical

problems. Since these agreements are closer to PI than to

MOTIS, the value of 1 will be used. This will not cause

( interworking problems between domains, because the only

deviation from PI is the InternalTracelnfo, which will not

be present in messages transferred outside of a domain.

7.8 ERROR HANDLING

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

7-54
December '89

7.8.1 MPDU Encoding

The MPDU should have a context-specific tag of 0, 1, or 2. If it

does not have one of these tags, it is not possible to figure out

who originated the message. Therefore, the way this error is

reported is a local matter.

7.8.2 Contents

Once delivery to the UA has occurred, it is not possible to

report errors in P2 information to the originator. In addition,

it seems unreasonable to insist that the MTA that delivers a message ensure that the P2 content of the message is acceptable.

As a result, the handling of content errors is a local matter.

7.8.3 Envelope

This section describes the handling of errors in message

envelopes. Some of the error conditions described below may be

detected in a recipient's 0/R Name. This may limit the reporting

MTA's ability to generate a nondelivery notification that

accurately reflects the erroneous 0/R Name in the

ReportedRecipientInfo . This handling of this situation is a local matter.

7.8.3.1 Pragmatic Constraint Violations

In all cases of pragmatic constraint violation, a nondelivery report should be generated with a ReasonCode of

unableToTransfer , and a Diagnos ticCode of

pragmaticCons traintViolat ion

.

7.8.3.2 Protocol Violations

a) If all required protocol elements are not present, a nondelivery report with a ReasonCode of unableToTransfer

and a DiagnosticCode of protocolViolation should be

generated.

b) 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.

7-55
December ' 89

7.8.3.3 0/R Names

a) The domain that has responsibility for delivering a message should also have the responsibility to send the

nondelivery notification if the message cannot be

delivered. Therefore, each MTA should only validate the

0/R Names of recipients with responsibility flags set to

TRUE. In addition, a nondelivery notification can only

be sent if the originator's 0/R Name is valid.

b) If any element in the 0/R Name is unrecognized or if the

CountryName , AdministrationDomainName , and one ofPrivateDomainName 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)

.

c) 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 , arabiguousORName , and uaUnavailable

.

7.8.3.4 Tracelnformation

a) Since non-relaying domains need not do loop suppression,

domains with responsibility for delivering the message

need not be concerned about the semantics of the

Tracelnformation, that is, arrival time and converted

EncodedlnformationTypes can be provided to the UA

without inspection by the MTAs of the domain as long as the Tracelnformation is properly encoded according to

X.409.

b) When a message is accepted for relay, the relaying

domain must check that a Tracelnformation SEQUENCE has

been added by the domain that last handled the message.

If the appropriate Tracelnformation was not added, this

should be treated as a protocolViolation (sec.

7.8.3.2).

c) In addition, the relaying domain must check that the

information was added in the sequence defined by the

7-56
December '89

rules for adding Tracelnformation in the CCITT X.400

Implementor ' s Guide. If the sequence is invalid, then a nondelivery report should be generated with a ReasonCode

of unableToTransfer and a diagnosticCode of

invalidParameters

.

Note: It would be desirable for the CCITT to add a diagnostic code of invalidTracelnformation to

allow a more meaningful description of this

problem. A request for this new diagnostic code

will be submitted.

7.8.3.5 InternalTracelnfo

This section applies only to MTAs which follow the

agreements of section 7.7.

a) When a message is accepted for relay from another MTA in

the domain, the relaying MTA must check that an InternalTracelnfo SEQUENCE has been added by the MTA

that last handled the message. If the appropriate

InternalTracelnfo was not added, this should be treated

as a protocolViolation (sec. 7.8.3.2).

b) In addition, the relaying MTA must check that the

information was added in the sequence defined by the

rules for adding Tracelnformation in the CCITT X.400

Implementor ' s Guide. If the sequence is invalid, then a nondelivery report should be generated with a ReasonCode

of unableToTransfer and a diagnosticCode of

invalidParameters

.

Note: It would be desirable for the CCITT to add a diagnostic code of invalidTracelnformation to

allow for a more meaningful description of this

problem. A request for this new diagnostic code

will be submitted.

7.8.3.6 Unsupported X.400 Protocol Elements

The protocol elements defined in X.400 but unsupported by

this profile are: the deferredDelivery and

PerDomainBilaterallnfo parameters of the UMPDUEnvelope , the

ExplicitConversion parameter of Recipientlnfo , and the

alternateRecipientAllowed and contentReturnRequest bits of

the PerMessageFlag. Appropriate actions are described below

for domains that do not support the protocol elements.

7-57
December '89

7.8.3.6.1 deferredPe 1 ivery

The delivering 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 and a DiagnosticCode of

noBilateralAgreement

.

7.8.3.6.2 PerDomainBilaterallnfo

If a delivering domain receives this element, the

element can be ignored.

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

requested conversion could not be performed along the

route. If delivery is not possible, then a nondelivery

report should be generated with a ReasonCode of

conversionNotPer formed with no DiagnosticCode.

7.8.3.6.4 alternateRecipientAl lowed

If a delivering domain receives this element the element

can be ignored.

7.8.3.6.5 contentReturnRequest

If a delivering domain receives this element, the

element can be ignored.

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

7-58
December ' 89

7.8.3.7.1 Priority

Additional values for Priority have been suggested by at

least one group of implementors as upward compatible

changes to the X.400 Recommendations. Therefore, if a PRMD receives an unexpected value for Priority, and this

value is greater than one byte in length, a nondelivery

report should be generated with a ReasonCode of

unableToTransfer and DiagnosticCode of

invalidParameters . If the value is less than or equal

to one byte, the PRMD can either generate a nondelivery

report as previously specified or interpret the Priority

as normal and deliver or relay the message.

7.8.3.7.2 ExplicitConversion

When an unexpected value is received for

ExplicitConversion, it should be handled as in section

7.8.3.6.3.

7.8.3.7.3 ContentType

If the ContentType is not supported by the delivering

MTA, then a nondelivery report should be generated with

a ReasonCode of unableToTransfer, and a DiagnosticCode

of contentTypeNotSupported.

7.8.3.8 Additional Elements

In the absence of multilateral agreements to the contrary,

receipt of privately tagged elements and protocol elements

in addition to those defined in X.400 will result in a nondelivery report with a ReasonCode of unableToTransfer and

a DiagnosticCode of invalidParameters.

The exceptions to this are the MOTIS elements. The

treatment of MPDU's containing these MOTIS extensions is

described in section 7.6.11.

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

7-59
December '89

7.9 MHS USE OF DIRECTORY SERVICES

7.9.1 Directory Service Elements

a) Recommendation X.400 recognizes the need of MHS users

for a number of directory service elements. Directory

service elements are intended to assist users and their

UAs in obtaining information to be used in submitting

messages for delivery by the MTS . The MTS may also use directory service elements to obtain information to be

used in routing messages. Some functional requirements

of directories have been identified and are listed

below.

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

.

b) In addition to functionality, a number of operational

aspects must be considered. These include

user-friendliness, flexibility, availability, expendability

,

and reliability.

c) 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.

7-60
December ' 89

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.

7.9.2 Use of Names and Addresses

a) It is recognized that these agreements enable a wide variety

of naming and addressing attributes (see sec. 7.5.3.5

ORName Protocol Elements) wherein each PRMD may adopt

particular routing schemes within its domain.

b) With the exception of the intra-domain connection

agreements

These agreements make no attempt to recommend a standard

practice for electronic mail addressing.

c) 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.

d) Further, each PRMD may adopt naming and addressing

schemes wherein the user view may take a form

entirely different from the attributes reflected in

table 7.9. And, each PRMD may have one user view

for the originator form and another for the

recipient form, and perhaps other forms of user

addressing. In some cases (e.g., receipt

notification) these user forms must be preserved

within the constraints of these implementation

agreements. However, mapping between one PRMD user

form to another PRMD user form, via the X.400 ORName

attributes of these agreements, is outside the scope

of these agreements.

7.10 CONFORMANCE

7-61
December '89

7.10.1 Introduction

In order to ensure that products conform to these implementation

agreements , it is necessary to define the types and degrees of

conformance testing that products must pass before they may be

classified as conformant . This section defines the conformance

requirements and provides guidelines for the interpretation of

the results from this type of testing.

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.

7.10.2 Definition of Conformance

For this section, the term conformance is defined by the

following

a) The tests indicated for this section are intended to

establish a high degree of confidence in a statement that

the implementation under test (lUT) conforms (or does not

conform) to the agreements of this section.

b) Conformance to a service element means that the information

associated with the service element is made accessible to

the user (person or process) whenever this agreement says

that this information should be available.

Accessible means that information must be provided

describing how a user (person or process)

o causes appropriate information to be displayed, or

o causes appropriate information to be obtained.

c) 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.

d) Conformance to the protocols requires:

o that MPDUs correspond to instances of syntactically

correct data units, ,

7-62
December '89

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,

o correct sequences of protocol data units in responses

(resulting from protocol procedures).

Statements regarding the conformance of any one implementation to this profile are not complete unless a Protocol Implementation Conformance Statement (PICS) is

supplied.

The term "Implementation Under Test" (lUT) 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.

Claiming Implementation Conformance

o An implementation which claims to be conformant as an ADMD must adhere to the agreements in sections 7.5 and

7.6.

o An implementation which claims to be conformant as a PRMD must adhere to the agreements in section 7.5.

o An implementation which claims to be conformant as a relaying PRMD must adhere to the agreements in section

7.5 and the appropriate sections of 7.7.

o An implementation which claims to be conformant to the

intra-domain connection agreements must adhere to the

agreements in section 7.5 and the appropriate sections

of 7.7.

7-63
December '89

7.10.3 Conformance Requirements

7.10.3.1 Introduction

Conformance to this specification requires that all the

services listed as supported in sections 7.5, 7.6, and if

appropriate, 7.7 of these agreements are supported in the

manner defined, in either the CCITT X.400 Recommendations or these agreements. It is not necessary to implement the

recommended practices of section 7.12, Appendix B, in order

to conform to these agreements

.

It is the intention to adopt, where and when appropriate the

testing methodology and/or the abstract test scenarios

currently being defined by the CCITT X.400 Conformance

Group. However, it is recognized that formal CCITT

Recommendations relating to X.400 Conformance Testing will

not be available until 1988. It is also recognized that

aspects of these agreements are outside the scope of the

CCITT, and that other organizations will have to provide

conformance tests in these cases.

7.10.3.2 Initial Conformance

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

the purposes of testing interoperability, only a subset of

this specification will initially be tested.

Note: By claiming conformance to this subset of

information the vendor or carrier CANNOT claim

conformance to this entire specification.

There are two aspects to the requirements, interworking and

service, as described in the following sections.

7-64
December '89

7.10.3.2.1 Interworklng

The interworking requirements for conformance implies

that tests be done to check for the syntax and semantics

of protocol data elements for a system as defined by the

classification scheme of sections 7.5.2.1.1 and 7.7.5.2.

For a relay system, the correct protocol elements should

be relayed as appropriate. For a recipient system, a message with correct protocol elements must not be

rejected where appropriate.

7. 10.3.2.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,

o replyToUsers

,

o importance

,

o sensitivity,

o IA5Text Bodypart.

7-65
December '89

7 .11 APPENDIX A: INTERPRETATION OF X.400 SERVICE ELEMENTS

The work on service element definitions is limited to those that are defined as 'supported' in section 7.5 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.

7-66
December '89

Original Encoded Information Types Indication

It is required that both an originating and recipient domain be able to

support IA5 text. Support for other encoded information types, for the

purposes of message transfer between domains, will depend on the

existence of bilateral or multi- lateral agreements.

The use of the 'unspecified' form of encoded information type should only

be used when the UMPDU content represents an SR-UAPDU or contains an auto -forwarded IM-UAPDU.

The original encoded information type of a message is not meaningful

unless a message is converted en route to the recipient. These

agreements support only IA5 text, which should not undergo conversion.

The original encoded information types should be made accessible to the

recipient for upward compatibility with the use of non-IA5 text message

body parts

.

Registered Encoded Information Types

A UMPDU with an 'unspecified' 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 O/R names of the other recipient(s) of the

message, as defined in the PI envelope, in addition to the O/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.

7-67
December '89

Blind Copy Recipient Indication

It should be considered that the recipient's UA acts on behalf of the

recipient, and therefore may choose to disclose all BCC recipients to

each other. Therefore it is the responsibility of the originating domain

to submit two or more messages, depending on whether or not each BCC

should be disclosed to each other BCC.

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

.

7-68
December '89

Forwarded IP message Indication

The following use of the original encoded information type in the context

of forwarded messages is clarified:

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 7B 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 IA5 body parts,

each one representing a paragraph of text.

7-69
December '89

7.12 APPENDIX B: RECOMMENDED X.400 PRACTICES

It is not necessary to follow the recommended practices when claiming

conformance to these agreements

.

7. 12.

1

RECOMMENDED PRACTICES IN P2

1. ORDescriptor

- Vendors following the NIST/OSI Workshop guidelines shall,

whenever possible, generate the ORName portion of an ORDescriptor in ALL IPM heading fields.

2. ForwardedlPMessage BodyParts

ForwardedlPMessage BodyParts should be nested no deeper than

eight. There is no restriction on the number of

ForwardedlPMessage BodyParts at any given depth.

3. Deliverylnformation

It is strongly recommended that Deliverylnformation 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 EncodedinformationType ( 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.

7.12.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 5 minutes).

In instances where this delay is not required or necessary,

report a localSystemProblem.

2. S-U- EXCEPTION-REPORT reason codes can be interpreted as follows

o receiving ability jeopardized (value 1)

7-70
December '89

Possible meaning: The receiving RTS knows of an impending system shutdown.

o local ss-User error (value 5)

Possible meaning: The receiving RTS needs to

resynchronize the session dialogue.

o irrecoverable procedure error (value 6)

Possible meaning: The receiving RTS has had to delete a partially received APDU, even though some minor

synchronization points have been confirmed.

o non specific error (value 0)

Possible meaning: The receiving RTS cannot handle the

APDU (for example, because it was too large) and wishes

to inform the sending RTS not to try again.

o sequence error (value 3):

Possible meaning: The S -ACTIVITY-RESUME request

specified a minor synchronization point serial number

which does not match the checkpoint data.

3. For purposes of identifying an MTA during an RTS Open, OS

I

addressing information should be used. This addressing

information is conveyed by lower layer protocols and is

reflected by the calling and called SSAP parameters of the

S-CONNECT primitives.

MTA validation and identification are related, but separate,

functions. The mTAName and password protocol elements of

the RTS user data should be used for validation, rather that

identification, of an MTA. The RTS initiator and responder

may independently require each other to supply mTAName and

password.

The CallingSSUserReference parameter of the S-CONNECT

primitives should only have meaning to the entity that

encoded it and should not be used to identify an MTA.

7.12.3 RECOMMENDED PRACTICES FOR ORName

Table 7.9 stipulates that the StandardAttributeList must contain

either PrivateDomainName or OrganizationName . It is recommended

that, for both originator and recipients in a private domain, the

PrivateDomainName field be used.

It is recommended that there should be a DomainDefinedAttribute

to be used in addressing UAs in existing mail systems, in order

to curtail the proliferation of different types of

7-71
December ' 89

DomainDefinedAttributes 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 DomainDefinedAttribute has the type name "ID" (in

uppercase) . It contains the unique identifier of the UA used in

addressing within the domain. This DomainDefinedAttribute is to

be exclusively used for routing within the destination domain

(i.e., once routed to that domain via the mandatory components of

the StandardAttributeList) ; any other components of the

StandardAttributeList may be provided. If they conflict delivery

is not made.

The contents of this parameter need not be validated in the

originating domain or any relaying domain, but simply transferred

intact to the next MTA or domain.

Class 2 and class 3 MTAs in a PRMD should allow administrators to

decide the number of OrganizationalUnits that should appear in

user names, instead of imposing a software controlled limit which

is less than four. This is desirable because when two different

vendors impose different limits on the number of

OrganizationalUnits in a name, it becomes difficult for the

administrator to choose a sensible naming scheme.

There are existing mail systems that include a small set of non- Printable String characters in their identifiers. For these

systems to communicate with X.400 messaging systems, either for

pass-through service or delivery to X.400 users, gateways will be

employed to encode these special characters into a sequence of

Printable String characters. This conversion should be

performed by the gateway according to a common scheme and before

insertion in the ID DDA, which is intended to carry electronic

mail identifiers. X.400 User Agents may also wish to perform

such conversions.

It is recommended that the following symmetrical encoding and

decoding algorithm for non-Printable String characters be

employed by gateways. The encoding algorithm maps an ID from an ASCII representation to a PrintableString representation. Any

non-printable string characters not specified in the table are covered by the category "other" in the table below.

7-72
December ' 89

The principal conversion table for the mapping is as follows:

Table 7B.1. Printable string to ASCII mapping

ASCII Character Printable String Character

% (percent) (P)

@ (at sign) (a)

! (exclamation) (b)

" (quote mark) (q) _ (underline) (u)

( (left paren.

)

(1)

) (right paren,

)

(r)

other (3DIGIT)

where 3DIGIT has the range 000 to 377 and is interpreted as the octal

encoding of an ASCII character.

To encode an ASCII representation to a PrintableString , the table and the

following algorithm should be used:

IF current character is in the encoding set THEN

encode the character according to the table above

ELSE

write the current character;

continue reading;

To decode a PrintableString representation to an ASCII representation,

the table and the following algorithm should be used:

IF current character is not "(" THEN

write character

ELSE

(look ahead appropriate characters;

IF composite characters are in the above table THEN

decode per above table

ELSE

write current character;

} continue reading;

Class 2 and class 3 MTAs in a PRMD should allow administrators to

decide the number of OrganizationalUnits that should appear in user names, instead of imposing a software controlled limit which

is less than four. This is desirable because when two different

vendors impose different limits on the number of

7-73
December ' 89

OrganizationalUnits in a name, it becomes difficult for the

administrator to choose a sensible naming scheme.

7. 12.4 POSTAL ADDRESSING

For domains wishing to support postal (or physical) delivery

options, the following interim set of "nationally-defined" domain

defined attributes are recommended. The CCITT will define

Standard Attributes in support of physical delivery in its 1988

Recommendations; this is only an interim solution.

CCITT will also be addressing the services associated with

physical delivery. This interim solution does not address the

end-to-end service aspects of physical delivery; in particular,

the following IPM service elements do not currently extend

outside of the X.400 environment:

o alternate Recipient Assignment

o PROBE

o Receipt Notification / Non-Receipt Notifications

o Grade of delivery

"Delivery" means passing a message from the MTS to the physical

delivery system (PDS), and not to the user (or user agent).

The following three DDAs are recommended to be used to specify a postal (or physical) address:

CNTRPC encodes the country and postal code for postal delivery.

The DDA value is of the form "Country?Postalcode" (for

example, "USA722096" ) . The country field is optional,

the postal code is optional; the separator ("?") is not.

If both country and postal code are missing, this DDA

should not be specified.

PDA 1 The country and postal code fields are free-form text.

PDA 2 These two DDA (signifying Postal Delivery Address

strings 1 and 2) form a 256 character free-form postal

address. Fields are separated by a question mark ("?").

There is no implied separator between PDAl and PDA2

.

The meaning of the fields are defined by each domain

supporting the physical delivery interface. PDAl

contains the first 128 characters, PDA2 the next 128

characters. If the PDA string is less than 128

characters, PDA2 is not used.

7-74
December '89

For example, if the domain interprets the PDA fields as lines,

the address

Mr. John Smith

Conway Steel

123 Main Street

Reston VA 22096

would be encoded as follows:

type = "PDAl" value = "Mr. John Smith?Conway Steel?123 Main

Street?Reston VA"

CNTRPC = "722096"

7.12.5 EDI use of X.400

7.12.5.1 Introduction and Scope

This is a guideline for EDI data transfer in an X.400

environment conforming to the NIST agreements. These

recommended practices outline procedures for use in

transferring EDI transactions between trading partner

applications in an attempt to facilitate actual X.400

implementation by EDI users.

The scope of this guideline is to describe specific

recommendations for adopting X.400 as the data transfer

mechanism between EDI applications.

7.12.5.2 Model

The MHS recommendations can accommodate EDI through the

approach illustrated below. Many Message Transfer (MT)

service elements defined in the X.400 recommendations are particularly useful to the EDI application.

7-75
December '89

X.400 Message (1 EDI interchange)

Envelope > PI Control

Information

Content >

One

EDI

Interchange

MHS Message

This diagram depicts an EDI content (1 EDI interchange)

enveloped by the PI MHS envelope. All the MT Services

defined in the X.400 Recommendations may be used for EDI.

However, it is not required to support optional or non- essential services to exchange EDI data between EDI users. When an EDI user submits an EDI Trade Document to the EDI

User Agent, the EDI UA will submit the EDI content plus PI

envelope to the Message Transfer System (MTS)

.

The EDI UA must support the essential MT Services as defined

in these Agreements; for example, as a minimum, to provide

default values for services not elected by the EDI user,

such as Grade of Delivery.

Note: MT Services are not necessarily made available by

the EDI UA to the EDI user.

7-76
December '89

7.12.5.3 Protocol Elements Supported for EDI

The following Pi protocol elements will be used to support

EDI applications:

Content Type

For EDI applications, the content type will be 0

(undefined content)

.

Original Encoded Information Types

Any EIT defined in the X.400 Recommendations may be used

to specify the encoding of EDI content. However, for

ANSI X12 EDI applications in particular, it is expected

that the "undefined" and "laSText" EIT's will normally

be used, with "undefined" used to signify the EBCDIC

character set.

7.12.5.4 Addressing and Routing

It is anticipated that connection of some existing systems

to an X.400 service for EDI purposes will be by other than

X.400 protocols, at least in the short term.

EDI messages entering the X.400 environment will therefore

need to have X.400 0/R Names added to identify the

origination and recipient trading partners, typically by

means of local directory services in the origination domain

which will map EDI identifiers/addresses into 0/R Names.

Such 0/R Names will contain Standard Attributes as defined

in table 7.9 and for recipient trading partners will at

least identify the destination domain.

In the case of trading partners outside the X.400

environment, it is expected, however, that there will be cases where message delivery will require the provision of

addressing information beyond that which can be carried in

Standard Attributes. In such cases. Domain Defined

Attributes are recommended to be used.

The syntax of this DDA is as defined in table 7.9, with a single occurrence having the type name "EDI" (uppercase) and

a value containing the identifier/address of the trading

partner. For ASC X12 purposes, specifically, this value

will comprise the 2 digit interchange ID qualifier followed

by the interchange ID (max 15 characters) . Routing on this

DDA shall only occur, if at all, in the destination domain.

7-77
December '89

7.12.6 USA Body Parts

It is recommended that UAs can generate any USA Body Part, as defined in Section 7.5.3.6.2, and that they can receive such body

parts as well. reception of USA Body Parts does not imply

further processing by the UA, but merely that the body part is

made available, with a indication of its registered body part

identifier, to another process or deposition in a file.

Generation implies the reverse of this process.

7.12.7 Recommended Practices for Binary Data Transfer

The capability to transfer binary data, such as those generated

by word/document processing, spreadsheets, or graphics

applications among X.400 system is a useful and desirable

feature. Many messaging systems provide such capability today.

It is recommended that transfer of binary data through 1984-based

systems be achieved using the Unidentified BodyPart in P2 with

the ASNl definition recaptured as follows:

BodyPart : := CHOICE { [0] IMPLICIT lASText

[14] IMPLICIT Unidentified

. . . )

Unidentified : := OCTET STRING

Note: the Unidentified BodyPart is included in 1984 X.400

Implementor ' s Guide, Version 6, and is renamed as BilaterallyDefinedBodyPart in 1988 X.400 Series with the same tag and definition.

Additionally the binary data can be identified by a text

string in the subject heading or in an IA5Text body part

preceding the Unidentified BodyPart.

When the Unidentified BodyPart is present in a P2

message, the undefined(O) bit of the PI

EncodedlnformationTypes will be set. If the lASText

bodypart is also present, the IA5text(2) bit will also

be set.

The binary data is the raw data as generated by user

applications. Besides encapsulating it for transfer

purposes, X.400 systems do not encode or interprete the

binary data in any way further. How the data is encoded

or decoded is defined by the cooperating user

7-78
December ' 89

applications. How the data is injected into X.400

systems or transferred out of X.400 systems to the user

applications, or how the user applications are invoked

to process the data is a local implementation issue and

not defined.

7.12.8 Recommended Practice for Office Document Architecture

(PDA') Transfer

It is recommended that the conveyance of ODA documents through

1984-based X.400 systems be achieved using the following schemes:

(a) In P2:

An ODA document will be transferred as a single body part

with tag 12, recaptured as follows:

BodyPart : := CHOICE { [0] IMPLICIT IA5Text

oda [12] IMPLICIT OCTET STRING

. . . }

The content of the Octet String will contain a value of type

OdaBodyPart as follows:

OdaBodyPart : := SEQUENCE { OdaBodyPartParameters

,

OdaData }

The Parameters and Data components are defined in Annex E of

CCITT Recommendation T.411 (1988) (ISO 8613-1).

(b) In PI:

Both the undefined bit (bit 0) and the ODA bit (bit 10) of

the EncodedlnformationType will be set when an ODA document

is present in P2

.

7-79
December '89

7.13 APPENDIX C: RENDITION OF lASText AND T61String CHARACTERS

7.13.1 GENERATING AND IMAGING lASText

The characters that may be used in an lASString are the graphic

characters (including Space), control characters and Delete of

the IA5 character repertoire ISO 646.

The graphic characters that 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 to start a new line

CR FF to start a new page (and line)

LF . . LF to show empty lines (always after one of the

preceding combinations)

.

The other control characters or the above control characters in

different combinations may be used but have no guaranteed effect.

The character Delete may occur but has no guaranteed effect. The

IA5String in a P2 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.

7.13.2 GENERATING AND IMAGING T61 String

For further study.

7-80
December ' 89

7.14 APPENDIX D: DIFFERENCES IN INTERPRETATION DISCOVERED THROUGH

TESTING OF THE MHS FOR THE CeBlt 87 DEMONSTRATION

Several interworking problems were discovered through mult i -vendor

testing. These problems, and recommendations for solutions to them

are discussed in this appendix.

7.14.1 ENCODING OF RTS USER DATA

The password is defined as an ANY in the X.400 Recommendations,

and implementor ' s groups have decided to use an lASString for

this field. There was some confusion about what the X.409

encoding for this lASString would be, and the correct encoding

is

class: context specific

form: constructor

id code : 1 length: length of contents

contents: (primitive encoding)

lASString: 16

length: length of contents

contents: the password string

class: context specific

form: constructor

id code : 1 length: length of contents

contents: (constructor encoding) left as an exercise for the

reader

Implementations should be prepared to receive any X.409 type for

the password because of its definition as an ANY.

7. 14.2 EXTRA SESSION FUNCTIONAL UNITS

One vendor proposed more than the required set of functional

units on opening the session connection, and the receiver

rejected the connection. All debate aside about whether the

initiator should have proposed units outside of the required set, or whether the receiver should have rejected the connection, the

set of functional units can be negotiated in a straightforward

way. The following is recommended.

If the initiator proposes using more than the required set of

functional units, the responder should specify the set of

functional units that it would like to use (which should include

the required set) in the open response. The session

7-81
December '89

implementations will automatically use the intersection of the

units proposed by both sides.

If the initiator proposes using less than the required set of

functional units, the responder should reject the connection.

Unfortunately, there is not an appropriate RefuseReason for

rejecting the connection, so instead of refusing the connection

in the response to the S- CONNECT, the receiver should issue an S

U-ABORT with an AbortReason of protocolError . Note that it is

valid to issue an S-U-ABORT instead of responding to the SCONNECT. A problem report has been submitted to the CCITT

requesting the addition of a RefuseReason for this situation.

If the responder proposes using less than the required set of

functional units, the session connection is established before

the initiator can check for this. If too few functional units

have been proposed, the initiator should abort the connection

using S-U-ABORT, with an abort reason of protocolError.

7 . 14.

3

MIXED CASE IN THE MTA NAME

The MTA name is frequently exchanged over the telephone when two

systems are being configured to communicate with one another. I one such telephone exchange, the casing of the MTA name was not

specified, the MTA name consisted of both upper and lower case

letters, and one of the implementations compared MTA names for

equality in a case sensitive manner. Consequently, connections

failed until the problem was detected and repaired. It is

recommended that the MTA name be compared for equality in a case insensitive manner, and that the password be compared for

equality in a case sensitive manner.

7. 14.4 X.410 ACTIVITY IDENTIFIER

The X.400 Implementor ' s Guide recommends that the activity

identifier be X.409 encoded, but this is only a recommendation

and not a requirement. Consequently, receiving systems cannot

assume that the activity identifier will be X.409 encoded.

7.14.5 ENCODING OF PER RECIPIENT FLAG AND PER MESSAGE FLAG

In the definition of the PerRecipientFlag in X.411, there is a statement that the last three bits are reserved, and should be

set to zero. It is unclear whether those bits are unused in the

X.409 encoding. Receivers should accept encodings with either

zero or three unused bits. A problem report has been submitted

to the CCITT asking for clarification.

7-82
December '89

Though there is not any statement in X.411 about the last four

bits of the PerMessageFlag , some vendors have encoded this with

zero unused bits, and some have encoded it with four unused bits.

The PerMessageFlag should be encoded with at least four unused

bits

.

7 14. 6 ENCODING OF EMPTY BITSTRINGS

There are three valid encodings for an empty bitstring: a constructor of length zero, a constructor of indefinite length

followed by the end-of-contents terminator, and a primitive of

length one with a zero octet as the value.

7.14.7 ADDITIONAL OCTETS FOR BITSTRINGS

Nothing in X.409 constrains an implementation from sending two,

three, four, or even more octets for a bitstring that fits into one octet, with the undefined bits set to zero. Note that the

number of excess octets is bounded by the pragmatic constraints

guidelines of the CCITT X.400 Implementor ' s Guide for all of the

bitstrings in PI.

7.14.8 APPLICATION PROTOCOL IDENTIFIER

If a value other that 1 is received in the applicationProtocol of

the pUserData in the PConnect, NIST implementations will reject

the connection. If CEN/CENELEC implementations receive a value

other than 8883 for this field, they will reject the connection.

This is an unfortunate state of affairs, because if NIST

implementations accept the value of 8883 without supporting the

MOTIS service elements, they would be misrepresenting themselves.

To make matters worse, CEPT uses a value of 1, but relays MOTIS

elements, which means that MOTIS elements will be relayed to

implementations using a value of 1 to demonstrate that they do

not support MOTIS. Work is continuing to try to find a solution

that will allow European implementations to interwork with U.S

implementations.

7.14.9 INITIAL SERIAL NUMBER IN S- CONNECT

This should be implemented in accordance with section 3.5.1 E4 of

the Implementors ' Guide.

7-83
December '89

7 14. 10 CONNECTION DATA ON RTS RECOVERY

It is clarified that the ConnectionData is identical in both the

S -CONNECT. request and the S -CONNECT . response . The value of the

ConnectionData is the old Session Connection Identifier.

7.14.11 ACTIVITY RESUME

If an activity is being resumed on a new session connection, it

is not clear from X.410 and X.225 whether all four of the calledss-user reference, the calling-ss-user reference, the common

reference, and the additional reference information should be

specified in the S -ACTIVITY-RESUME, or whether one of the ss- user-references should be absent. It is also unclear whether the

called-ss-user reference should be identical to the calling-ssuser reference if both are present. Consequently, receivers

should be tolerant of this situation. Appropriate problem

reports will be submitted to the CCITT asking for clarification.

7. 14. 12 OLD ACTIVITY IDENTIFIER

The Old Activity Identifier in S -ACTIVITY-RESUME refers to the

original activity identifier.

7.14.13 NEGOTIATION DOWN TO TRANSPORT CLASS 0

For European implementations, X.410 specifies that class 0

transport must be supported. However, it is permissible for an initiator to propose a higher class as the preferred class,

provided that class 0 appears as the alternate class in the TConnect PDU. A responding implementation can choose to use either the preferred or alternate class, but again, must be able

to use class 0. In other words, for private to private

connections in Europe, class 0 transport is required.

This conflicts with the NIST agreements, since class 0 is only

required if one of the partners in a connection is an ADMD.

7-84
December '89

7.15 APPENDIX E: WORLDWIDE X.400 CONFOI^ANCE PROFILE MATRIX

Y CONFORMANCE (E)

implies a conformance problem for European products in the United States.

Y CONFORMANCE (US)

implies a conformance problem for U.S. products in Europe.

o The A/311 profile is specified in Env 41 202, the A/3211 profile

in Env 41 201

o No TTC protocol classification for RTS exists.

o The notation XA indicates "X" for PRMDs and "Y" for ADMDs,

i.e., "M/G" would be Mandatory for PRMDs and Generatable for

ADMDs.

7-85
December ' 89

Table 7E.1. Protocol element comparison of RTS

RTS element NIST A/311 A/3211 PROBLEM Y/N

PConnect M M M N

DataTrans ferSyntax M 0 M 0 M 0 N

PUserData M M M N

checkpoints ize H H H N

windows ize H H H N

dialogueMode H H H N

connectdata M M M N

applicationProtocol G 1 H 1 R 8883 N

H 8883

Connect ionData

Open G G G N

Recover G H G N

Open

RTSUserData G G G N

Recover

SessionConnectionID G G G N

RTSUserData

MTAName G G G N

Password G G G N

null G G G N

SessionConnectionID

CallingUserReference M M M N

CommonReference M M M N

Addi t ionalRe fInf

o

H H H N

PAccept G G G N

DataTrans ferSyntax M 0 M 0 M 0 N

(Continued on next page.)

7-86
December '89

Table 7E,1. Protocol element comparison of RTS , continued

RTS element NIST A/311 A/3211 PROBLEM (Y/N)

PUserData M M M N

Checkpoints ize H H H N

Windows ize H H H N

Connec tionData M

TV7 N

PRefuse G G G N

RefuseReason M M M N

SSUserData G G G N

(in S- TOKEN -PLEASE)

Abortlnformation G G G N

(in S-U-ABORT)

AbortReason H H H N

reflectedParameter X X X N

7-87
December '89

Table 7E.2. Protocol element comparison of PI

PI Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

ORnarae

S tandardAttr ibuteLls t M M M M N See Note 4

DomainDefAttributeList X X X G Y See Note 5

StandardAttributeList

CountryName R R R M N

ISO R R N

X.121 H H Y Conformance (E)

Other X X Y Prot Vio

AdrainistrationDoraainName R R G M N

... if PrintableString R G N

... if numericString H H Y Conformance (E)

X.121 Address X X/R X Y Conf(US)See Note 1 Terminal ID X X/G X Y Conf(US)See Note 1 PrivateDomainName G G G G N

OrganizationName G G G G N UniqueUAidentifier X X/G X Y Conf(US)See Note 1 PersonalName G G G G N

OrganizationalUnit G G G G N

DoraainDefinedAt tribute X X X G N

Type M M M M N

Value M M M M N

PersonalName

Surname M M M M N

GivenName G G G G N

Initials G G G G N

GenerationQualifier G X X X Y Conformance (E)

GlobalDomainldentifier

CountryName M M n M

MN AdministrationDomainName M M G M Y Proto Vio

PrivateDomainldentifier R/H H R M/X N

MPDU

UserMPDU G G G G Y TTC required

MPDU size is

32K

DeliveryReportMPDU G G G G N

ProbeMPDU H H H H N

7-88
December '89

Table 7E.2. Protocol element comparison of PI, continued

PI Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

UserMPDU

UMPDUenvelope M M M M N

UMPDUcontent M M M M N

UMPDUenvelope

MPDUidentifier M M M M N

origlnatorORname M M M M N

originalEncodedTypes G H H G Y Conformance (E)

ContentType M M M M N

UAcontentID H H H H N

Priority u \j (j N

PerMessageFlag G G G G N

De ferredDe 1 ive ry X X X X N

PerDoraainBilatlnfo X X X X N

Recipientlnfo M M M M Y TTC MPDU 32K

Tracelnformation M M M M N

MOTIS -> LatestDe livery X N

MOTIS -> InternalTracelnfo M/P P N

UMPDUcontent M M M M N

MPDUidentifier

GlobalDomainldent M M M M N

lASstring M M M M N

PerMessageFlag

DiscloseRecipients H C B MTT H Y Conformance (US)

H at UA ? Y Conformance (US)

ConversionProhibited G G G G N

AlternatRecipAl lowed H G @ MTL H X Y Conformance (US)

H at UA ? Y Conformance (US)

ContentReturnReques t X X X X

MOTIS -> redirectionProhibited X N

PerDomainBilaterallnfo

CountryName M M M M N

AdminDomainName M M G M Y Prot Vio

MOTIS -> PrivateDoraainName G N

Bilaterallnfo M M M M N

(Continued on next page

7-89
December '89

Table 7E.2. Protocol element comparison of PI, continued

PI Protocol IN lb 1 A/A /n 1 J i i A/ J Z J. 1 PPORT PM /'Y/Kf^

Delive ryReportContent

original MPDUident n n

M n JN intermediate Trace A/ Vj AY AY AY

UAcontentiu G G G G N

ReportedRecipientInf

o

M M M M Y TTC 256 max returned un

un AY AY 1 ocelli. U L JlldllC c billing information AV AY AY AY IN

ReportedRecip lent Info

recipient ORname M nM rlM Mn MIN extensions Identifier M M M M

MN PerRecipientFlag M M M M MIN Las tTrace Information M M M M N intendedRecipient H H H H N

SupplementaryInfo A/ n YA AY AY MOTIS-> Reassignment Info X N

MOTIS -> Reassignmentlnfo

MOTIS -> intendedRecipient M N MOTIS -> reasonForReassignment un

M

Las tTrace Information

arrival M M M M N

convertedEnc InfoTypes un Y Conformance (E)

Report M M M n MIN

Report

Deliveredinf

o

G G G

1-M

N See Note 6

NonDe liveredinfo n\j n\j r; N

Deliveredlnfo

delivery M M M M N

TypeofUA R/H H R M/G N

NonDe 1 ive r edinfo

ReasonCode M M M M N

DiagnosticCode H H H H N MOTIS -> UAprofile Identifier X N

MOTIS -> UAprofile Identifier

MOTIS -> ContentType M N

MOTIS -> EncodedlnfoTypes M N

(Concinued on next pag

7-90
December ' 89

Table 7E.2. Protocol element comparison of PI, continued

PIi. ± Prn^r^rr^^ L 1. \J \^\J\^\J IN 1 0 i A/A 1 1 J LI A /T 0 1 1 TTT' DDAT3T VM /V /M ^ rK(JDL,ilrl (,1/IN_)

ProbeEnvelope

probe M M M M IN M M M M NT

^-« u11 ucn L. X ype nM rl rl n. IN UArontpnt"Tn Hn uii yjL i.gi.iLaxJiiiic xnx u 1 ypes un

url Y Conformance (E)

TTflppTn'Fn'rTnflt"'! on M M M M PerMessageFlag G G G G N

ContentLength H H H H N

X X X Y N

w X L/ X C& 1 \v X L ft A> V M M M M Y TTT mpy

MOTIS-> InternalTraceTnf

o

M/P p N

Recipientlnfo

RecipientORname M M M M N

Extensionldentifier M M M M N

X C2 X IvcL. Xp XCILL-x Xclg M M M M M

ExplicitConversion X X X X N MOTIS -> OriginatorReqAlternatRecip X N

MOTIS-> Reassignmentlnfo X N

PerRecipientFlag

ResponsibilityFlag M M M M N

ReportRequest M M M M N

UserReportRequest M M M M N

Tracelnformation

GlobalDomainldent M M M M N

DomainSuppliedlnfo M M M M N

(Continued on next page

7-91
December '89

Table 7E.2. Protocol element comparison of PI, continued

PI Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

DomainSuppliedlnfo

arrival M M M M N

deferred X X X X N

action M M M M N

(0=relayed) G G G N Note:

Re-routing not

required.

(l=rerouted) H H H N

MOTIS-> (2=recipientReassigned) H N

converted H G H H Y Conformance (US)

previous H G G X Y Conformance (US)

(Note: G is

inconsistent with

action (relayed)

being "H.")

ORname

EncodedlnforraationTypes

BitString M M M M N See Note 3 G3NonBasicParameters X X X X N

Te le texNonBas icParams X R X X Y Conformance (US)

PresentationAbilities X X X X N

DeliveryReportMPDU G G M G N

DeliveryReportEnvelop M M M M N

De 1 ive ryRepor tContent M M M M N

DeliveryReportEnvelope

report M M M M N

originator ORname M M M M N

Tracelnforraation M M M M N

InternalTracelnfo M/P P N

(Continued on next page

7-92
December '89

Table 7E.3. Protocol element comparison of P2

P2 Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

UAPDU

IM UAPDU G G G G N

SR_UAPDU X X X X N

IM_UAPDU

Heading M M M M N

Body M M M M N

Heading

IPmessagelD M M M M N

Originator ORname R R R M/G N

AuthorizingUsers H H H H Y TTC 16 max PrimaryRecipients G G G G Y TTC 256 max CopyRecipients G G G G Y TTC 256 max

un

ununun V1 TTP iiv> 9SA mav max

InReplyTo G G G G N

Obsoletes H H H H Y TTC 8 max CrossReferences H H H H Y TTC 8 max

tJ \JLU 1 & W \-r G G G G N

ExpiryDate H H H H N

ReplyBy H H H H N

£\.cp i.y LiJU^Ki L ^ un un

unun Importance H H H H N

Sensitivity H H H H N

All f~n 'Fm'xjfl Trip (\ H H H N

MOTIS-> CirculationList X N

MOTIS-> ObsoletingTime X N

IPmessagelD

ORname H H H H N

PrintableString M M M M N

ORdescriptor

ORname H H H N See Note 6

FreeFormName H H H > N

TelephoneNumber H H H G N

Recipient

ORdescriptor M M M M N

ReportRequest X X X X N

ReplyRequest H H H H N

(Continued on next page

7-93
December ' 89

Table 7E.3. Protocol element comparison of P2 , continued

P2 Protocol NIST A/311 A/3211 TTC PROBLEM CY/N)

MOTIS-> CirculationList

MOTIS-> CirculationMember X N

MOTIS-> checkmark M N

MOTIS-> membername M N

MOTIS-> OBsoletingTirae

lL\J L ± O ^ i. J. me H N

MOTIS-> IP_MessageID H N

Body

BodyPart G M M G Y Conformance (US)

SR_UAPDU

NonReceipt H H H N

Receipt H H H

_jh N

l< O T* ^ O /I M M M M N

ActualRecipient R R R G N

IntendedRecipient H H H H N

Converted X X X G N

MOTIS-> CirculationStatus X N

NonReceiptlnformation

Reason M M M M N

NonRece iptQual if ier H H H H N

=expired (value) 0 0 0 0 N

=obsoleted (value) 1 1 1 1 N

=subscriptionTerminated 2 2 2 2 N MOTIS-> =timeobsoleted (value) X N

Comments H H H X N

returned H X X X Y Conformance (E)

Receipt Information

Receipt M M M M N

TypeOfReceipt H H H G N

SupplementaryInfo X X X X N

(Continued on next pa

7-94
December '89

Table 7E.3. Protocol element comparison of P2 , continued

P2 Protocol NIST A/311 A/3211 TTC PROBLEM (Y/N)

BODYPART SUPPORT

o IA5 Text G G G N See Note 7 o TLX X X X N

o Voice X X X N

o G3FAX X X X N

o TIFO X X X N

o TTX X X/H X Y Conf(US)See Note 2 o VideoTex X X X N

o NationallyDefined X X X N

o Encrypted X X X N

o ForwardedlPmessage H H H N

o SFD X X X N

o TIFI X X X N

MOTIS-> o ODA X N

MOTIS-> o IS06937 Text H N

7-95
December '89

Note 1: It should be noted that the A/311 profile states: For routing

all ADMDs should support all Form 1 Variants of 0/R Name. All

PRMDs should support at least Form 1, Variant 1 form of OR Name.

Note 2: It should also be noted that the A/311 profile requires that all

ADMDs should support the reception of Teletex body parts for

delivery to their own UAEs

.

Note 3: An A/3211 implementation may generate MOTIS encoded information

types. See 7.6.11.

Note 4: Only Form 1 Variant 1 of 0/Rname shown for TTC , but TTC defines

other forms and variants . Form 1 Variant 1 recommended for PRMDs

and ADMDs, Form 1 Variant 2 also recommended for ADMDs.

Note 5: DDA's can be used to specify recipients in any Japanese domains

other than TTC, Assignment of DDAs for UAs within TTC domains is

not recommended.

Note 6: One of [Deliveredlnfo/NonDeliveredlnfo] must be present. TTC

encodes this as shown. Other profiles represent this by

classifying both protocol elements as generatable. A similar

situation exists with the P2 ORdescriptor

.

Note 7: TTC is expected to support IA5 for some international MHS

communications

.

7-96
December ' 89

7.16 APPENDIX F: INTERWORKING WARNINGS

ADMD name is to be encoded as a single space when configurations with

no ADMD's are present. It should be noted that this may change in

January 1988 so that the ADMD name is encoded as a zero length element

in such cases.

The NIST agreements allow implementation to generate MPDUs with no body parts. Such MPDUs will be rejected by European- conformant

systems. (Note this situation may change in January 1988)

In order to optimize the number of recipients you can read and reply

to, it is advisable to be able to generate all standard 0/R name attributes

.

7-97
I

I
December '89

MESSAGE HANDLING SYSTEMS

8.1 INTRODUCTION

This is an Implementation Agreement developed by the Implementor '

s

Workshop sponsored by the National Institute of Standards and

Technology to promote the useful exchange of data between devices

manufactured by different vendors. This Agreement is based on, and

employs protocols developed in accord with, the OSI Reference Model.

It provides detailed guidance for the implementor and eliminates

ambiguities in interpretations.

This is an Implementation Agreement for Message Handling Systems (MHS)

based on both the CCITT X. 400 (1988) series of Recommendations and the

similar (but not identical) ISO MOTIS standard (see References) . The

term 'MHS' is used to refer to both sources where a distinction is

unnecessary. Similarly, '1984' and '1988' are often used to

distinguish between the CCITT X. 400(1984) series of Recommendations

and the later sources.

This Implementation Agreement seeks to establish a common specification which is conformant with both CCITT and ISO with a view

to:

o Preventing a proliferation of incompatible communities of MHS

systems which are isolated for protocol reasons,

o Achieving interworking with implementations conforming to the

NIST Stable Implementation Agreements for CCITT 1984 X.400-based

Message Handling Systems, and

o Facilitating integration of other OSI-based services (e.g.,

Directory) within a single real system.

This initial Implementation Agreement is designed to encourage early

upgrade of existing 1984-based systems as follows:

o To add 1988 functionality (Message Store, remote User Agent,

etc) , and

o To provide a minimal conformant 1988 MHS as a firm basis for the

introduction of further 1988 services and features. Subsequent

versions of this Agreement will define such additional 1988

aspects as incremental enhancements.

However, it is considered that the NIST Stable Implementation

Agreements for CCITT 1984 X.400-based Message Handling Systems (ch. 7)

should not be withdrawn at this stage. It is anticipated that

X. 400 (1984) implementations will continue to provide a viable

8-1
December ' 89

alternative for applications that do not require the additional 1988

functionality for some time.

8.2 SCOPE

This Agreement specifies the requirements for MHS implementations

based on the 1988 MHS standards.

This Agreement applies equally to Private Management Domains (PRMDs)

and Administration Management Domains (ADMDs) . Four boundary

interfaces are specified, as illustrated in figure 8.1:

o Management Domain (MD) to MD,

o Message Transfer Agent (MTA) to MTA within a domain,

o MTA to remote Message Store (MS) or User Agent (UA) , and

o MS to remote UA.

MHS protocols other than the Message Transfer Protocol (PI), the

Message Transfer System Access Protocol (P3), the Interpersonal

Messaging Protocol (P2) , and the Message Store Access Protocol (P7) are beyond the scope of this Agreement. Issues arising from the use of other protocols are outside the scope of this document. This

Agreement describes the services provided at each interface shown in

figure 8.1.

MHS implementations may be configured as any single or multiple

occurrence or combination of MTA, MS and UA, as illustrated in figure

8.1. It is not intended to restrict the types of system that may be

configured for conformance to this Agreement (although it is equally

recognized that not all configuration types may be commercially

viable)

.

8-2
September 1990 (Stable)

Figure 8.1. Scenario Definition.

The 1988 MHS standards cover a wide and diverse range of functional areas,

not all of which would be relevant to every implementation. In order to

achieve a more precise definition of conformance requirements according to

the functionality supported by an implementation, and additionally to

facilitate future enhancement of this initial specification, the concept of

' Functional Groups ' has been introduced. Figure 8.2 shows the Functional

Groups covered by this Agreement and indicates where they are defined in

this chapter. Conformance requirements for support of Functional Groups by

particular configurations are specified in section 8.16.

In the context of these agreements, the term "Support" means that the

service provider makes the element of service (and related elements of

protocol) available to the service user. The service user provides adequate

access to invoke the elements of service and/or makes information associated

with the service element available. Additionally, for "Not Defined" or "Not

Applicable" elements, the service provider is not required to make the

element available to the service user. However, the service provider should

not regard the occurrence of the corresponding protocol elements as an error and should relay those elements. Naturally, protocol elements marked

critical for transfer must be processed per-X-;400 se^-iea" according to the

base standards.

8-3
September 1990 (Stable)

The following functional groups are covered by this Implementors Agreement:

a) The MT Kernel in clause 5;

b) The IPM Kernel in clause 6;

c) The Message Store in clause 7;

d) Remote User Agent support in clause 8;

e) Distribution Lists in clause 9.2 (which are for further study);

f) Use of Directory in clause 9.3;

g) MHS Management in clause 10 (which is for further study)

;

h) Security in clause 11;

i) The Physical Delivery Access Unit in clause 12.1 (which is for

further study)

;

j) Other Access Units in clause 12.2 (which are for further study);

k) Conversion in clause 13 (which is for further study)

;

1) Redirection in clause 14 (which is for further study) ; and,

m) The EDI Messaging Service in clause 15 (which is for further

study)

.

8-4
September 1990 (Stable)

MT Kernel

(8.5)

IPM Kernel

(8.6)

Message Store

(8.7)

Remote User

Agent Support

(8.8)

Use of Directory

(*)

(8.9.3)

Distribution

Lists (*)

(8.9.2)

Security (*)

(8.11)

Physical

Delivery (*)

(8.12.1)

Other Access

Units (*)

(8.12.2)

Conversion (*)

(8.13)

( * - for further

study )

Figure 8.2. MHS Functional Groups

8-4-1

March 1990 (Stable)

8.3 STATUS

This version of the Implementation Agreements for Message Handling

Systems (MHS) is under development. It is based on the CCITT

X. 400(1988) Recommendations and ISO MOTIS (10021, parts 1-7)

standards

.

It is intended that the Stable Implementation Agreements will

initially include an Agreement which specifies a minimal 1988-based

MHS implementation and support for Message Stores and remote User

Agents, and which addresses interworking with 1984-based

implementations. The remaining features specified in the 1988

standards will be covered in subsequent versions of this Agreement.

This initial version has not yet been aligned with other MHS profiles,

so changes may be necesary in the future for international

harmonization, (e.g., support for international character repertoires

and conversion.)

8.4 ERRATA

I No -Errata -to -Stable -material: -at -this -feimeT Alignment Errata to tables

I in sections 8.17.1 to 8.17.3 have been included as indicated.

8.5 MT KERNEL

8.5.1 Introduction

This section specifies the requirements for a minimal 1988-based

MTS implementation (i.e., MTA) which is capable of interworking

with 1984-based MTAs . The 'base' MT Service specified in this

section does not include:

o

o

o

o

o

oo

Message Store (see 8.7)

Remote UA (see 8.8)

Use of Directory Services (see 8.9.3)

Distribution Lists (see 8.9.2)

Security (see 8.11)

Interworking with Physical Delivery systems or Specialized

Access (see 8.12)

Conversion (see 8.13)

Such a minimal 1988-based MTA will have the following

capabilities in order to achieve interworking with 1984-based

MTAs and to facilitate migration to full 1988 operation:

o It will be protocol-conformant to 1988 PI;

8-5
March 1990 (Stable)

o It will downgrade 1988 PI to 1984 PI when relaying to 1984-

based MTAs , as specified in Annex B of X.419 (see 8.5.5);

o It will support both 'normal' mode and 'X. 410-1984'

(' pass through ' ) mode protocol stacks (i.e., as required by

ISO and CCITT respectively)

.

8.5.2 Elements of Service

This section specifies the requirements for support of MT

Elements of Service by an MTA conforming to the MT Kernel

Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as follows:

Mandatory (M) - the Element of Service must be supported and made

available to the service user;

Optional (0) - the Element of Service may be supported, but is

not required for conformance to this Agreement;

Not Defined/Not Applicable (-) - the Element of Service is not

defined by this Agreement or is otherwise not applicable in the

particular context;

To Be Determined (*) - the support classification for the Element

of Service has yet to be determined.

The requirements for support of MT Elements of Service for

origination and reception and (where relevant) relaying are distinguished. Elements of Service which are new in the 1988 MHS

standards are indicated as (1988).

An MTA must support those Basic MT Elements of Service and MT

Optional User Facilities defined in clause 19 of X. 400(1988) as listed and qualified in tables 8.1 and 8.2 below.

8-6
December '89

Table 8.1. MT Kernel: Basic MT Elements of Service

Element of Service Origination Reception Relaying

Access Management M^

Content Type Indication M M

Converted Indication M M M

Delivery Time Stamp Indication M

Message Identification M M

Non-delivery Notification M M M

Original Encoded Information

Types Indication M M

Submission Time Stamp Indication M M

User/UA Capabilities

Registration (1988) m1

Notes

1) A local matter in the case of co- located UA/MTA and/or

MS/MTA configurations.

8-7
December '89

Table 8.2. MT Kernel: MT Service Optional User Facilities

Element of Service Origination Reception Relaying

Alternate Recipient Allowed M

0

- Alternate Recipient Assignment - 02 - Conversion Prohibition M M M

Conversion Prohibition in Case

of Loss of Information (1988) 0 0 0

Deferred Delivery m3 0 0

Deferred Delivery Cancellation m6 - - Delivery Notification M M - Disclosure of Other Recipients M M M

DL Expansion History Indication - - DL Expansion Prohibited m5 - - Explicit Conversion 0 0 0

Grade of Delivery Selection M M M

Hold for Delivery - M-^ - Implicit Conversion 0 0 0

Latest Delivery Designation (1988 0 0 0

Multi Destination Delivery M M M

Originator Requested Alternate

Recipient (1988) 0 0 - Prevention of Non-delivery

Notification 0

Probe M M M

Redirection Disallowed by

Originator (1988) 0 0

Redirection of Incoming

Messages (1988) 0

Requested Delivery Method (1988 ) M M

Restricted Delivery (1988) 0

Return of Content 0 0 0

Notes

1) A local matter in the case of co- located UA/MTA and/or

MS/MTA configurations

.

2) If Alternate Recipient Assignment is supported on

reception, then support of Alternate Recipient Allowed is

Mandatory on reception; otherwise, support of Alternate

Recipient Allowed is not applicable on reception.

3) Support of this MT Element of Service is Mandatory for

conformance reasons, but may be performed as a local

matter to the originating MTA.

8-8
September 1990 (Stable)

Table 8.2. MT Kernel: MT Service Optional User Facilities (Cont.)

4) Support of this MT Element of Service refers only to the

delivery of DL expansion history and not to the performing

of DL expansion (see 8.9.2).

5) Support of this MT Element of Service does not imply the

capability to perform DL expansion (see 8,9.3).

6) Messages should be held in the originating MTA to provide

support for this element of service.

8.5.3 MTS Transfer Protocol (Pi)

The requirements for support of MTS Transfer Protocol (PI)

elements are detailed in section 8.17.1 (Appendix A).

Support of MTS Transfer Protocol application contexts by an MTA

is classified as in table 8.3.

Table 8.3. Application Contexts Classification

Application Context Support

mts- transfer -protocol- 1984

mts- transfer -protocol

mts- transfer

Mandatory

Mandatory

Mandatory

Use of the underlying services to support these application

contexts is specified in section 8.14,

8.5.4 MTS - APDU Size

See Working Document.

8.5.5 1988/84 Interworking Considerations

See Working Document.
September 1990 (Stable)

8.6 IPM KERNEL

8.6.1 Introduction

This section specifies the requirements for a minimal 1988-based

IPMS implementation (i.e., UA) which is capable of interworking

with 1984-based UAs . The 'base' IPM Service specified in this

section does not include:

o Message Store (see 8.7) o Remote UA (see 8.8)

o Use of Directory Services (see 8.9.3)

o Distribution Lists (see 8.9.2)

o Security (see 8.11)

o Interworking with Physical Delivery systems or Specialized

Access (see 8.12)

Such a minimal 1988-based UA will have the following capabilities

in order to achieve interworking with 1984-based UAs and to

facilitate migration to full 1988 operation:

o It will continue to support content type P2 (encoded as integer 2) on origination and reception;

o It will support receipt of P2 (encoded as integer 22)

;

o It may originate P2 encoded as integer 22 , but the

guidelines specified in clause 20.2 of X. 420(1988) are to be

followed, i.e., the content type shall be encoded as integer

2 unless 1988 P2 protocol elements are present.

All IPM UAs must support either MTS Submission and Delivery based

on the protocol classifications in section 8.17.3, or MS

Submission and Retrieval based on the protocol classifications in

section 8.17.4. However, how such information is conveyed to/from

the MTS or MS in the case of a co- located UA is a local matter,

and will not necessarily be subject to conformance verification.

8.6.2 Elements of Service

This section specifies the requirements for support of IPM

Elements of Service by a UA conforming to the IPM Kernel

Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as defined in section 8.5.2.

8- 10
December '89

The requirements for support of IPM Elements of Service for

origination and reception are distinguished. Elements of Service

which are new in the 1988 MHS standards are indicated as (1988).

A UA must support those Basic IPM Elements of Service and IPM

Optional User Facilities defined in Clause 19 of X. 400(1988) as listed and qualified in tables 8.4 and 8.5 below.

Table 8.4. IPM Kernel: Basic IPM Elements of Service

Element of Service Grig Recep

Access Management

Content Type Indication

Converted Indication

Delivery Time Stamp Indication

IP-message Identification

Message Identification

Non-delivery Notification

Original Encoded Information

Types Indication

Submission Time Stamp Indication

Typed Body

User/UA Capabilities Registration (1988)

mJ

M

M

M

M

M

M

M

M-" M

M

M

M

M

M

M

M

M^

Notes

1) In the case of a co- located UA/MTA or co- located UA/MS

,

the method and extent to which this Element of Service

is provided is a local matter; it is not necessarily

testable in the absence of support for the P3 or P7

protocol

.

8-11
December '89

Table 8.5. IPM Kernel: IPM Service Optional User Facilities

Element of Service Orig Recep

Alternate Recipient Allowed 0

- Alternate Recipient Assignment - 0

Authorizing Users Indication 0 M

Auto -forwarded Indication 0 M

Blind Copy Recipient Indication 0 M

Body Part Encryption Indication 0 M

Conversion Prohibition M M

Conversion Prohibition in Case of Loss of

Information (1988) 0 0

Cross Referencing Indication 0 M

Deferred Deliver}' M - Deferred Delivery Cancellation 0

- Delivery Notification M - Disclosure of Other Recipients 0 M

DL Expansion History Indication (1988) - M

DL Expansion Prohibited (1988) M - Expiry Date Indication 0 M

Explicit Conversion 0 - Forwarded IP-message Indication 0 M

Grade of Delivery Selection M M

Hold for Delivery - 0

Implicit Conversion - 0

Importance Indication 0 M

Incomplete Copy Indication (1988) 0 0

Language Indication (1988) 0 M

Latest Delivery Designation (1988) 0 - Multi-Destination Delivery M - Multi-part Body 0 M

Non-receipt Notification Request 0 M^

Obsoleting Indication 0 M

Originator Indication M M

Originator Requested Alternate Recipient (88) 0 - Prevention of Non-delivery Notification 0 - Primary and Copy Recipients Indication M M

Probe 0 - Receipt Notification Request Indication 0 0

Redirection Disallowed by Originator (1988) 0

Redirection of Incoming Messages (1988) 0

Reply Request Indication 0 M

Replying IP-message Indication M M

Requested Delivery Method (1988) M

Restricted Delivery (1988) 0

Return of Content 0

Sensitivity Indication 0 M

Subject Indication M M

Use of Distribution List (1988) 0

8-12
December '89

Table 8.5. IPM Kernel: IPM Service Optional User Facilities (Cont.)

Notes

1) Support of Non-Receipt Notification Request on reception does not require the capability to generate

a non-receipt notification in the case of an implementation in which a non- receipt condition cannot occur

.

8.6.3 Interpersonal Messaging Protocol (P2)

The requirements for support of Interpersonal Messaging Protocol

(P2) elements are detailed in section 8.17.2 (Appendix A).

8.6.4 Body Part Support

This section specifies the requirements for support of IPM body

part types by a UA conforming to this Agreement.

The classification scheme for support of IPM body part types is as defined in section 8.5.2.

The requirements for support of IPM body part types for

origination and reception are distinguished. Body part types

which are new in the 1988 MHS standards are indicated as (1988).

A UA must support those IPM body part types defined in Annex E of

X. 420(1988) as listed and qualified in table 8.6 below. If an implementation supports a particular body part type for

reception, it should also be able to support that body part type

for reception if it is part of a forwarded message.

Any basic body part type that is supported on reception must be

supported as integer encoding (ASN.l context-specific identifier)

and as object identifier (externally-defined) encoding.

All body parts with integer-encoded identifiers in the range 0 up

to and including 16K-1 are legal. Body part integer-encoded

identifiers corresponding to X.121 country codes should be

interpreted as described in figure 8.5. These privately-defined

body part types are specified as an interim measure to provide

backward compatibility with 1984 MHS implementations. For

interworking between UAs based on the 1988 (or later) MHS

standards, it is strongly recommended that the externally-defined

body part be used instead.

8-13
December ' 89

Table 8.6. IPM Kernel: Body Part Types

Body Part Type Orig Recep

IA5Text M M

Voice 0 0

G3Facsimlle 0 0

G4Classl (TIFO) 0 0

Teletex 0 0

Videotex 0 0

Encrypted 0 0

Message (Forwardedl PMe s s age

)

0 M

MixedMode (TIFl) 0 0

Bi lateral lyDefined (Unidentified) 0 0

National lyDefined 0 0

External lyDefined (1988) 0 0/M^

Private lyDefined (see figure 8.5) 0 0

GeneralText (1988 - extended) * *

Notes

1) Any basic body part type that is supported on reception as integer encoding must also be supported

as object identifier encoding. Support for all other

externally defined body parts is optional.

8-14
December '89

BodyPart : := CHOICE { ia5-text [0] IA5TextBodyPart

,

externally-defined [15] External lyDef inedBodyPart

,

[234] UKBodyParts,

[310] USABodyParts

,

}

Where UKBodyParts and USABodyParts (privately defined) are defined as:

SEQUENCE {BodyPartNumber , ANY)

BodyPartNumber : := INTEGER

These privately-defined body part types are specified as an interim measure to provide backward compatibility with 1984

MHS implementations. For interworking between UAs based on

the 1988 (or later) MHS standards, it is strongly

recommended that the externally-defined body part be used

instead.

The undefined bit in PI EncodedlnformationTypes must be set

when a message contains a privately defined body part. Each

UA that expects such body parts should include undefined in

the set of deliverable EncodedlnformationTypes it registers

with the MTA.

Body part numbers are interpreted relative to the body part

type in which they are used. NIST registers body part

niambers for privately-defined formats within the United

States

.

Figure 8.5. Privately-Defined Body Parts.

8.7 MESSAGE STORE

8.7.1 Introduction

This section specifies Agreements for implementation of the

Message Store (MS) Functional Group. The MS is responsible for

accepting delivery of messages on behalf of a single end-user,

and retaining the messages until the end-user's UA is able to

retrieve them. Message submission and some administration

services are provided via "pass- through" to the MTS . Figure 8.6

illustrates the logical relationship of the MS to the UA and MTS.

8-15
December '89

UA <

RETRIEVAL

INDIRECT

SUBMISSION

ADMINISTRATION

K >H

MS <

>

DELIVERY

SUBMISSION

->

ADMINISTRATION

K >l

MTS

Figure 8.6. Message Store Model

The Agreements in this section specify the Message Store's use of

the retrieval, delivery, and administration services. Agreements

on submission services are specified in section 8.8, which

describes support for the remote UA.

The goal of the Agreements in this section is to define the

minimal set of features which are necessary to provide useful

Message Store services, independent of the MTA implementation

version (i.e., 1984 or 1988).

8.7.2 Scope

The scope of the Agreements in this section is depicted in figure

8.7 below, and is confined to the services and protocols between

the boundaries shown (marked with asterisks) . Requirements for

the UA and MTA are addressed only to the extent that they affect

the Message Store and remote User Agent services and protocols.

This reflects the additional services required at the UA to

support MS access and at the MTA to support a remote MS.

*

1 P7 P3

*

1

UA MS MTA

I

Figure 8.7. Scope of Message Store Agreements.

The UA, MS and MTA configuration is not restricted; any of these

components may be co- located, although they are depicted as logically separate. In the case of a co- located UA and MS, a proprietary interface may be used instead of P7 . In the case of

8-16
December '89

a CO- located MS and MTA, a proprietary interface may be used

instead of P3

.

8.7.3 Elements of Service

This section specifies the requirements for support of Elements

of Service to provide a Message Store conforming to the Message

Store Functional Group of this Agreement.

The classification scheme for support of Elements of Service is as defined in section 8.5.2.

Support for Elements of Service is specified both for the Message

Store itself and for the User Agent.

Table 8.7. Message Store: Elements of Service

Element of Service UA MS

Stored Message Deletion M M

Stored Message Fetching M M

Stored Message Listing M M

Stored Message Summary M M

Stored Message Alert 0 0

Stored Message Auto Forward 0 0

8.7.4 Attribute Types

Requirements for support of the attributes used in the Message

Store are detailed in sections 8.17.5 and 8.17.6 (Appendix A),

section 8.17.5 specifies support for the General Attributes of

the Message Store, while section 8.17.6 specifies support for the

IPM Message Store Attributes.

There are two classes of support for General Attributes in the

Message Store: Basic and IPM.

The Basic MS is intended to support the use of the MS as a continuously available, reliable device (such as a spooling

entity) for receiving, storing, and forwarding messages and

reports. The Basic MS is not required to support any IPM

attributes

.

The IPM MS provides more flexible access to the General

Attributes as well as supporting IPM Attributes.

8-17
December ' 89

IPM User Agents can make use of either the Basic or IPM MS.

section 8.17.6 is to be read in accordance with Annex C of X.420

(1988) .

8.7.5 Pragmatic Constraints for Attribute Types

There are no additional pragmatic constraints for attribute types

beyond those of the basic standards.

8.7.6 Implementation of the MS with 1984 Systems

While the Message Store is part of the 1988 MHS standards,

implementation of MS services with a 1984 MTA is possible. In

order to interoperate with other 1984 MHS systems,

implementations with this configuration should adhere to the

following guidelines:

o The UA must generate 1984 P2 PDUs ;

o The UA must identify the content protocol as integer 2 to

the MS;

o The MS must be co- located with the MTA unless 1988 P3

support is provided on the 1984 MTA as well.

To meet these guidelines, the UA may be implemented as follows:

o The UA could conform to X. 420(1984), with 1988 UA extensions

for utilizing the MS services;

o The UA could be a 1988 UA with restrictions on protocol

elements generated and by identifying the content type as integer 2 rather than 22. No 1988-specific elements should

be generated.

Details of the interface between the 1988 MS and the 1984 MTA

when CO- located are beyond the scope of these Agreements.

8.7.7 MS Access Protocol (P7)

The requirements for support of MS Access Protocol (P7) elements

by an MS and a remote MS-user are detailed in section 8.17.4

(Appendix A)

.

The requirements for support of MS Access Protocol (P7)

application contexts by an MS and an MS-user are as specified in

clauses 6.1 and 10.1 of X. 419(1988) (ISO 10021-6) with the

8-18
December '89

additional requirement that an MS-user must at least support the ms-access application context, as defined in table 8.8.

Table 8.8. Application Contexts Support for P7

Application Context MS MS-user

ms-access

ms- re liable -access Mandatory

Optional

Mandatory

Optional

Use of the underlying services to support these application

contexts is specified in section 8.14.

8.7.8 MTS Access Protocol (?3)

The requirements for support of MTS Access Protocol (P3) elements

by an MTA and an MS where the MS is not co- located with the MTA

are detailed in section 8.17.3 (Appendix A).

The requirements for support of MTS Access Protocol (P3)

application contexts by an MTA and an MS in such a scenario are

as specified in clauses 6.1 and 10.1 of X. 419(1988) (ISO 10021-6)

with the additional requirement that a remote MS must at least

support the mts-access and mts-forced-access application

contexts, as defined in table 8.9.

Table 8.9. Application Contexts Support for P3

Application Context MTA MS

mts-access

mts-forced-access

mts- re liable -access

mts- forced- re liable -access

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Use of the underlying services to support these application

contexts is specified in section 8.14.

REMOTE USER AGENT SUPPORT

8-19
December '89

8.8.1 Introduction

This section specifies Agreements for implementation of the

Remote User Agent Functional Group, i.e., for support of an IPM

UA that is not co-located with its MTA. Support of other classes

of UA is for further study.

The goal of the Agreements in this section is to define the

minimal set of features which are necessary to provide useful

remote User Agent services, independent of the MTA implementation

version (i.e., 1984 or 1988).

8.8.2 Scope

The scope of the Agreements in this section is depicted in figure

8.8, and is confined to the services and protocols between the

boundaries shown (marked with asterisks) . Requirements for the

UA and MTA are addressed only to the extent that they affect the

remote User Agent services and protocols. Access to a Message

Store by a remote User Agent is covered in section 8.7.

1 P3

*

1 UA MTA

I

Figure 8.8. Scope of Remote User Agent Agreements.

8.8.3 Elements of Service

This section specifies the requirements for support of Elements

of Service for conformance to the Remote User Agent Functional

Group of this Agreement.

The classification scheme for support of Elements of Service is as defined in section 8.5.2.

Support for Elements of Service is specified both for the MT

Service and for the IPM Service, and is in addition to the

support requirements specified in sections 8.5 and 8.6 if this

Functional Group is supported.

8-20
September 1990 (Stable)

Table 8.10. Remote User Agent Support: MT Elements of Service

Element of Service Origination Reception

Access Management M M

Hold for Delivery M

User/UA Capabilities Registration M

Table 8.11. Remote User Agent Support: IPM Elements of Service

Element of Service Origination Reception

Access Management M M

Hold for Delivery M

User/UA Capabilities Registration M

8.8.4 MTS Access Protocol (P3)

The requirements for support of MTS Access Protocol (P3) elements

by an MTA and an MTS -user (whether UA or UA/MS) where the MTS- user is not co- located with the MTA are detailed in section

8.17.3 (Appendix A).

The requirements for support of MTS Access Protocol (P3)

application contexts by an MTA and an MTS -user in such a scenario

are as specified in clauses 6.1 and 10.1 of X. 419(1988) (ISO

10021-6) with the additional requirement that a remote MTS-user

must at least support the mts-access and mts-forced-access

application contexts, as defined in table 8.12.

Table 8.12. Application Contexts Support for P3

Application Context MTA MTS-user

mts-access

mts-forced-access

mts- re liable -access mts-forced- re liable -access

Mandatory

Mandatory

Optional

Optional

Mandatory

Mandatory

Optional

Optional

Use of the underlying services to support these application

contexts is specified in section 8.14.

8-21
September 1990 (Stable)

8.9 NAMING. ADDRESSING & ROUTING

See Working Document.

8.10 MHS MANAGEMENT

For further study.

8.11 MHS SECURITY

See Working Dociament.

8. 12 SPECIALIZED ACCESS

See Working Document.

8.13 CONVERSION

See Working Document.

8.14 USE OF UNDERLYING LAYERS

8. 14.

1

MTS Transfer Protocol (PI)

The PI protocol is mapped onto the Reliable Transfer Service

Element (RTSE) either in X. 410- 1984 mode or in normal mode, as specified in section 8.5.3. In X. 410-1984 mode, the RTSE makes

direct use of the services provided by the Session Layer, as specified in chapter 5 (Upper Layers) of the Stable

Implementation Agreements. In normal mode, the RTSE makes use of

the services provided by the Association Control Service Element

(ACSE) and Presentation Layer, as defined in chapter 5 (Upper

Layers) of these Agreements.

8.14.2 MTS Access Protocol (P3) and MS Access Protocol (P7)

The P3 and P7 protocols make use of the services provided by the

Remote Operations Service Element (ROSE) , Association Control

Service Element (ACSE), Presentation Layer, and, optionally, the

Reliable Transfer Service Element (RTSE) , as defined in chapter 5 (Upper Layers) of these Agreements. It is recommended that RTSE

be used for recovery purposes when the implementation uses a Transport Class other than 4.

8-22
December '89

8.15 ERROR HANDTJNP,

Editor's Note: The material in 8.15 was not explicitly included

in a proposal brought to the OIW Plenary in

December 1989.

This section describes appropriate actions to be taken upon receipt of

protocol elements which are not supported in this profile: malformed

PDUs , unrecognized 0/R Name forms, content errors, errors in reports,

and unexpected values for protocol elements.

An implementation must be able to report all error conditions which

may occur with the appropriate error information as defined in the

referenced base standards. An implementation must be able to handle

receipt of all error indications which are defined in the referenced

base standards. An implementation must also be tolerant of any

additional error indications which are not currently defined, but is

not required to be able to interpret such error information.

8.16 CONFORMANCE

For this section, the term conformance is as defined in ISO 9646.

Bilateral agreements between domains may be implemented in addition to

the requirements stated in this document. Conformance to this

Agreement requires the ability to exchange messages without use of

bilateral agreements .

In order to achieve a more precise definition of conformance

requirements according to the functionality supported by an implementation, the concept of Functional Groups has been introduced.

A Functional Group is a set of related Elements of Service and

associated protocol elements which provide a discrete area of

functionality.

Conformance to this Agreement requires as a minimum that all Mandatory

Elements of Service listed in this chapter are supported in the manner

defined in the MHS standards, as qualified in this Agreement, for each

of the Functional Groups claimed. Any Optional Elements of Service

for which support is claimed must also be supported as defined in the

MHS standards and as qualified in this Agreement. Pragmatic

constraints shall be observed as specified in the CCITT X.400 (1988)

Series of Recommendations. It is not necessary to implement the

recommended practices of Appendix C in order to claim conformance to

this Agreement.

Conformance requirements for support of Functional Groups by

particular configuration types (see sec. 8.2) are listed below. An

8-23
December '89

implementation may claim conformance to multiple configuration types

(e.g., "MTA+UA" and "Class B MTA only").

Table 8.23. Conformance Requirements

Configuration^ MT

Kernel

IPM

Kernel

Functional Groups

MS'^ Remote DL

UA

Directory

MTA + UA^ m2 M 0 0 0

MTA + MS M MOO 0

MTA only^ : class A M 0 0

class B M M 0 0

class C M 0 0

MS + UA M M 0

MS only M *

UA only: P7 M M 0

P3 M M 0

Notes

1) There are three conformance levels defined for the MT Kernel in

this Agreement:

o A class 'A' MT Kernel implementation conveys a message, probe, or report to another MT Kernel using standard means. A class 'A' MT

Kernel is specifically implemented in order to transfer messages,

probes, and reports which have previously been transferred and

need not support submission and delivery. A class 'A' MT Kernel

may perform other activities such as originate reports, expand

distribution lists, and perform conversions.

o A class 'B' MT Kernel implementation supports submission,

delivery, and transfer using standard means, i.e., P3 and PI. A

class 'B' MT Kernel need not support the transfer of previously

transferred messages, probes, or reports.

o A class 'C MT Kernel implementation requires support for

transfer of messages, probes, and reports to another MT Kernel

using standard means. A class 'C MT Kernel does not require

support for the transfer of previously transferred messages,

probes, and reports, and message submission and delivery is

achieved by non-standard means.

8-24
December '89

An MTA may conform to one or more of the MT Kernel classes. For

example, a class 'B' or 'C MT Kernel which supports the transfer of

previously transferred messages, probes, and reports is also

conformant to a class 'A' MT Kernel. Figure 8.10 illustrates several

combinations of MT Kernel conformance classes. Additional

combinations are possible.

UA

MS

MTA

Class B

MTA

Class A

MTA

Class AB

Standard

Non-standard

MTA

Class C

UA

MS

UA

MS

Figure 8.10. MT Kernel Conformance Classes

2) Optional elements of the IPM Kernel need not be supported in the

MT Kernel in this configuration, for example Probe and Deferred

Delivery Cancellation.

3) The designation of a ' + ' in a configuration (e.g., 'MTA+MS')

implies that there is no exposed protocol in the interface

between the two components

.

4) There are two conformance levels defined for MS support:

o A Basic MS only requires support for the General Attributes as specified in section 8.17.5

o An IPM MS requires support from both the General Attributes and

IPM Attributes as specified in sections 8.17.5 and 8.17.6,

respectively.

8.17 APPENDIX A: MHS PROTOCOL SPECIFICATIONS

The following tables (8.25-8.30) specify the requirements for support

of MHS protocol elements for conformance to this Agreement. It should

be noted that the tables specify minimum support for conformance to

the relevant Kernel functional groups and where appropriate also

specify enhanced support requirements where one or more further

functional groups are claimed. All element support is subject to

further review and may be upgraded in later versions of this

Agreement

.

8-25
December '89

The protocol support classification scheme used in this version of

this Agreement is described below. However, it should be noted that

the scheme is currently under review both within the NIST X.400 SIG

and in the EWOS/ETSI MHS groups and is likely to be revised for later

versions of this Agreement.

The classification of support for a protocol element specifies the

requirements for implementations conforming to this Agreement to be

able to generate, receive and process that protocol element, as appropriate (the 'receiving' role includes relaying where

appropriate) . The classification of support for each protocol element

is relative to that for its containing element. Where subelements

within a containing element are not listed, then their support

classification shall be assumed to be that of the containing element.

Where the range of values to be supported for an element is not

specified, then all values defined in the base standard shall be

supported.

The classifications have been revised. The new classifications relate

to the classifications in the 1988 Stable Agreements as shown in table

8.24.

Table 8.24. Classification Changes

Former

Category

New

Originator

Category

Recipient

Category

Generatable (G)

Supported (H)

Mandatory (M)

Required (R)

Unsupported (X)

Mandatory (M)

Optional (0)

Mandatory (M)

Mandatory (M)

Optional (0)

Mandatory (M)

Mandatory (M)

Mandatory (M)

Mandatory (M)

Optional (0)

The support classifications are stated for both Origination and

Reception (0/R) in the following tables (8.25-8.30). The defined

support for each is stated within each classification.

Mandatory (M)

Origination : Implementations conforming to this Agreement shall

generate this element in all information objects in which, according

to the base standards, it shall occur.

Reception : Implementations conforming to this Agreement shall process

this element appropriately, and shall regard its absence as a protocol

violation unless otherwise specified in the base standards. When an MS or MTA receives a protocol element that according to the base standard

8-26
December ' 89

and this profile should be conveyed to another MHS entity (MTA, MS, or UA) , the MS or MTA is required to preserve the semantics of that

protocol element in the message conveyed.

Optional (0)

Origination : Implementations conforming to this Agreement may

optionally be capable of generating this protocol element, but are not

required to do so.

Reception : Implementations conforming to this Agreement may, but are not required to be capable of processing this protocol element other

than to observe any criticality indication. When an MS or MTA receives

a protocol element that according to the base standard and this

profile should be conveyed to another MHS entity (MTA, MS, or UA) , the

MS or MTA is required to preserve the semantics of that protocol

element in the message conveyed. The absence of this element should

not be assumed to convey any significance.

Note: Some protocol elements may not be conveyed, if

downgrading rules are applied.

To Be Determined (*) - the support classification for this protocol

element has yet to be determined.

8-27
December '89

8.17.1 MTS Transfer Protocol (PI)

Table 8.25. Classification of the PI Protocol Elements

MTS Transfer Protocol (Pi) Part 1 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

Operations

MTABind M M/M M/M MTABind

MTAUnbind M M/M M/M

MTSE See protocol elements

MessageTransfer M M/M M/M

ProbeTransfer M M/M M/M

ReportTransfer M M/M M/M

Arguments/Results

MTABind

ARGUMENT

<NULL> 0 0/M 0/M See Note 2 <SET> 0 M/M M/M

initiator -name M M/M M/M

initiator -credentials M M/M M/M

simple 0 M/M M/M

strong 0 0/0 0/0

security- context 0 0/0 0/0

RESULT

<NULL> 0 0/M 0/M See Note 2 <SET> 0 M/M M/M

responder-name M M/M M/M

re sponder- credentials M M/M M/M

simple 0 M/M M/M

strong 0 0/0 0/0

Notes

:

1) The MT Kernel implementation classes are defined in sec.

8. 16.

2) The action to be taken on receipt of null MTABind

authentication is that an implementation must understand the

semantics, but the form of authentication that is acceptable

is a local matter.

8-28
March 1990 (Stable)

MTS Transfer Protocol (Pi) Part 2 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

MTS-APDU

message M M/M 0/M

envelope M M/M M/M MessageTransferEnvelope

content M M/M M/M See P2 - else undefined

probe M M/M 0/M ProbeTransferEnvelope

report M M/M M/M

envelope M M/M M/M ReportTransferEnvelope

content M M/M M/M ReportTransferContent

Me ssageTransferEnvelope

message- identifier M M/M M/M MTSIdentifier

originator -name M M/M M/M ORName

original -encoded- informationtypes 0 M/M 0/0 Enco dedinfo rmat i onType s content- type M M/M M/M

built-in 0 M/M 0/0

external 0 0/M 0/0

content- identifier 0 0/M 0/0

priority 0 M/M 0/M All values

per-message- indicators 0 M/M 0/M

disclosure -of- recipients 0 0/M 0/M

implicit -conversion-prohibited 0 M/M 0/M

alternate -recipient -allowed 0 M/M 0/0

content- re turn- request 0 0/0 0/0

deferred-delivery- time 0 0/0 0/0

per- domain-bilateral

information 0 0/0 0/0 PerDomainBilaterallnfo

trace - information M M/M M/M Tracelnformation

extensions 0 M/M M/M ExtensionField

recipient- reassignmentprohibited 0 M/M M/M

dl- expansion- prohibited 0 M/M 0/M

convers ion- with- loss

prohibited KJ U/W r>u/n/M

latest -de livery- time 0 0/0 0/0 See X.411, 14.1.1 note 2 originator -re turn- address 0 0/0 0/0

originator- certificate 0 0/0 0/0

content -confidentialityalgorithm- identifier 0 0/0 0/0

message-originauthenticat ion- check 0 0/0 0/0

message -security- label 0 0/0 0/0

content- correlator 0 0/0 0/0

8-29
March 1990 (Stable)

MTS Transfer Protocol (PI) Part 3 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

dl - expans ion-his tory 0 0/M 0/M DLExpansionHistory

internal - trace - information 0 M/M M/M InternalTracelnfo

per -recipient -fie Ids M M/M M/M

recipient -name M M/M M/M ORName

original ly- specifiedrecip lent -number M M/M M/M

per-recipient- indicators M M/M M/M

explicit- conversion 0 0/0 0/0

extensions 0 0/M 0/M ExtensionField

originator-requestedalternate- recipient 0 0/0 0/0

requested-del ivery - me tho

d

0 M/M 0/M

phys ical - forwardingprohibited 0 0/0 0/0

physical -forwarding- address

request 0 0/0 0/0

physical -de livery -modes 0 0/0 0/0

registered-mail- type 0 0/0 0/0

recipient -number -for -advice 0 0/0 0/0

physical -rendition- attributes 0 0/0 0/0

physical-delivery-reportrequest 0 0/0 0/0

message- token 0 0/0 0/0

content- integrity-check 0 0/0 0/0

proof-of -de livery- request 0 0/0 0/0

redirection-history 0 0/M 0/M

ProbeTransferEnvelope

probe -identifier M M/M M/M MTSIdentifier

originator -name M M/M M/M ORName

original-encoded- informationtypes 0 M/M 0/0 EncodedlnformationTypes J r content- type M M/M M/M

built-in 0 M/M 0/0

external 0 0/M 0/0

content- Identifier 0 0/M 0/0

content - length 0 M/M 0/0

per-message- indicators 0 M/M 0/M

disclosure -of -recipients 0 0/0 0/0

implicit -conversion- prohibited 0 M/M 0/M

alternate -recipient -allowed 0 M/M 0/0

content- re turn- request 0 0/0 0/0

8-30 .

I
December '89

MTS Transfer Protocol (PI) Part 4 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element s 0/R 0/R See Note 1

pe r-domain-bi lateral

information 0 0/0 0/0 PerDomainBi later allnfo

trace - information M M/M M/M Tracelnformation

0 M/M M/M Extens ionFie Id rec ipient - reass ignmentprohibited 0 0/0 0/0

C A. L' dL IS X W 1.1 1. \J L L d.U J- \^^\X 0 M/M 0/M

conversion-with- loss - prohibited 0 0/0 0/0

originator -certificate 0 0/0 0/0

message - security- labe

1

0 0/0 0/0

content -correlator 0 0/0 0/0

nrobe-ori pin-authenticationcheck 0 0/0 0/0

dl- expans ion -hi story 0 0/M 0/M DLExpansionHistory

internal - trace - information 0 M/M M/M InternalTracelnfo

per -rec ipient- fields M M/M M/M

rec ipient -name M M/M M/M ORName

originally-specified- rec ipient -number M M/M M/M

per-recipient- indicators M M/M M/M

explicit -conversion 0 0/0 0/0

extens ions 0 0/M 0/M Extens ionFie Id

or iginator -requestedalternate- rec ipient 0 0/0 0/0

r e que sted-del ive ry - me thod 0 M/M 0/M

physical -rendition- at tributes 0 0/0 0/0

ypdi Tec t ion -hi Storv 0 0/M 0/M

ReportTransferEnvelope

report- identifier M M/M M/M MTSIdentifier

report -destination- name

wn M/M M/rl ORName

trace - information M M/M M/M Tracelnformation

extensions 0 M/M M/M Extens ionFie Id

message -security- label 0 0/0 0/0

or iginator-and-DL- expans ion- Or iginatorAndDL

history 0 M/M 0/0 Expans ionHistory

report ing-DL-name 0 0/0 0/0

reporting-MTA- certificate 0 0/0 0/0

report -origin- authenticationcheck 0 0/0 0/0

internal - trace - information 0 M/M M/M InternalTracelnfo

8-31
December '89

MTS Transfer Protocoi (PI) Part 5 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

ReportTransferContent

subj ect- identifier M M/M M/M MTSIdentifier

subj ect- intermediate - trace

information 0 M/M M/M Traceinformation

original-encoded- informationtypes 0 M/M M/M EncodedlnformationTypes

content- type 0 M/M M/M

built-in 0 M/M M/M

external 0 M/M M/M

content- identifier 0 M/M M/M

returned- content 0 0/M 0/0

additional- information 0 0/0 0/0

extensions 0 0/M 0/M ExtensionField

content -correlator 0 0/M 0/M

per -recipient -fie Ids M M/M M/M

actual -recipient -name M M/M M/M ORName

original ly- spec ifiedrecip lent -number M M/M M/M

per-recipient- indicators M M/M M/M

last- trace- information M M/M M/M

arrival- time M M/M M/M

converted- encodedinformation- types 0 M/M M/M EncodedlnformationTypes

report M M/M M/M

delivery 0 M/M 0/0

message -de livery- time 0 M/M M/M

type-of-MTS-user 0 M/M 0/0 All values =0/M

non- delivery 0 M/M M/M

non- delivery- reason- code 0 M/M M/M

non-delivery-diagnosticcode r\u U/n. U/M

originally- intended-recipientname 0 M/M M/M ORName

supplementary- information 0 0/0 0/0

extensions 0 M/M M/M Extens ionFie Id

redirection-history 0 M/M M/M Redirect ionHistory

phys ical - forwarding- address 0 0/0 0/0

recipient -certificate 0 0/0 0/0

proof -of -delivery 0 0/0 0/0

8-32
March 1990 (Stable)

MTS Transfer Protocol (PI) Part 6 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

Conunon Data Types

Enco de dlnfo rmat i onType s built-in-encoded- informationtypes M M/M M/M See Note 3 non-basic -parameters 0 0/0 0/0

external-encoded- informationtypes 0 0/M 0/M

MTSIdentifier

global-domain- identifier M M/M M/M GlobalDomainldentifier

local- identifier M M/M h/M

PerDomainBilaterallnfo

country -name M M/M M/M

administration- domain-name 0 M/M M/M DomainName

private-domain- identifier 0 M/M M/M DomainName

(only encoded as SEQ if

both present)

bilateral- information M M/M M/M

Tracelnformation

TracelnformationElement M M/M M/M

global-domain- identifier M M/M M/M GlobalDomainldentifier

domain-supplied- information M M/M M/M

arrival- time M M/M M/M

routing- action M M/M M/M

relayed 0 M/M M/M

rerouted 0 0/M 0/M

attempted- domain 0 0/M 0/M GlobalDomainldentifier

deferred- time 0 M/M M/M

converted- encodedinformation- types 0 0/M 0/M EncodedlnformationTypes

i~'\r\ air — Si i~ '1 f\T\c n /M n /M

redirected 0 0/M 0/M

dl-operation 0 0/M 0/M

ExtensionField

type M M/M M/M

criticality 0 0/M 0/M

for -submission 0 0/0 0/0

for- transfer 0 M/M M/M

for -de livery 0 M/M M/M

8-33
March 1990 (Stable)

MTS Transfer Protocol (PI) Part 7 of 9

MT Kernel Support by MTS Class Conunents /References

B/C A

Protocol Element S 0/R 0/R See Note 1

value M M/M M/M

DLExpansionHistory

DLExpansion M M/M M/M

ORAddre s sAndOp1 1 onaID i rec tory

Name M M/M M/M ORName

dl - expans ion- time M M/M M/M

InternalTracelnformation

InternalTracelnformationElement M M/M M/M

global-domain- identifier M M/M M/M GlobalDomainldentifier

mta-name M M/M M/M

mta- supplied- information M M/M M/M

arrival- time M M/M M/M

routing- action M M/M M/M

relayed 0 M/M M/M

rerouted 0 0/M 0/M

attempted 0

mta r\0 U/M U/M

domain 0 0/M 0/M GlobalDomainldentifier

deferred- time 0 0/M 0/M

other -act ions 0 0/M 0/M

redirected 0 0/M 0/M

dl-operation 0 0/M 0/M

Or iginatorAndDLExpans ionHis tory

originator- or- dl -name M M/M M/M

origination-or-expansion- time M M/M M/M

Redirect ionHis tory

Redirection M M/M M/M

intended- rec ip lent -name M M/M M/M

ORAddressAndOptionalDirectory

Name M M/M M/M ORName

redirection- time M M/M M/M

redirect ion- reason M M/M M/M

ORName

address M M/M M/M

standard- at tributes M M/M M/M

country -name 0 M/M 0/M CountryName

administration- domain-name 0 M/M 0/M DomainName

network- address 0 M/M 0/M

8-34
December '89

MTS Transfer Protocoi (Pi) Part 8 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

terminal- identifier 0 M/M 0/M

pr ivate - domain-name 0 M/M 0/M riomp U\JHICL 1J- TiN^mp L Lll exilic organization- name 0 M/M 0/M

numeric-user- identifier 0 M/M 0/M

personal -name 0 M/M 0/M

surname M M/M M/M

given-name 0 M/M 0/M

initials 0 M/M 0/M

generation- qualifier 0 M/M 0/M

organizational -unit -names 0 M/M 0/M

OrganizationUnitName M M/M 0/M

domain- defined- at tributes 0 M/M 0/M

DomainDefinedAttribute M M/M 0/M

type M M/M M/M

value M M/M M/M

extension- attributes 0 0/M 0/M Extens ionAt tribute common-name 0 0/M 0/M

teletex- common- name 0 0/M 0/M

teletex- organization -name 0 0/M 0/M

teletex -personal -name 0 0/M 0/M

te letex- organizational -unit

names 0 0/M 0/M

te letex- domain- definedattributes 0 0/M 0/M

pds-name 0 0/M 0/M

physical -de livery -country- name 0 0/M 0/M

postal-code 0 0/M 0/M

physical-delivery-office -name 0 0/M 0/M

physical-delivery-off icenumber 0 0/M 0/M

extension- OR- address

components 0 0/M 0/M

physical -de live ry-personalname 0 0/M 0/M

physical-deliveryorganizat ion- name 0 0/M 0/M

extension-physical -de liveryaddress -components 0 0/M 0/M

unformatted- postal -address 0 0/M 0/M

street-address 0 0/M 0/M

post-office -box -address 0 0/M 0/M

pos te - re stante- address 0 0/M 0/M

8-35
December '89

MTS Transfer Protocol (Pi) Part 9 of 9

MT Kernel Support by MTS Class Comments/References

B/C A

Protocol Element S 0/R 0/R See Note 1

im 1 fiup - no t" a 1 -namp 0 0/M 0/M

XOCclX 1 O O 1 — pUoLdX rto^ol — a^^VT Vm 1 t" q o cl U L L J. UU. L.6 o n /M / 11 extended- network- address 0 0/M 0/M

terminal - type 0 0/M 0/M

rli Tpr* t"OT*v - nflmp 0 0/o 0/o

Ex tens ionAt tribute

extension- at tribute - type M M/M M/M

cxcens ion acL-cj-Duce va j.ue Sri M CL/ M /M11 11M /M / n

GlobalDoraainldentif ier

country-name M M/M M/M CountryName

administration- domain- name M M/M M/M DomainName

private-domain- identifier 0 M/M 0/M DomainName

CountryName

xl21 -dec-code 0 0/M 0/M

iso-3166-alpha2-code 0 M/M 0/M

DomainName

numeric 0 0/M 0/M

printable 0 M/M 0/M

Notes (continued)

3) An implementation is only required to generate EITs that

correspond to the body parts it is capable of generating.

8-36
December '

8

8.17.2 Interpersonal Messaging Protocol (P2)

Table 8.26. Classification of the P2 Protocol Elements

Interpersonal Messaging Protocol (P2) Part 1 of 3

Support by

UA

Protocol Element S 0/R Comments/References

InformationObj act

ipm 0 M/M IPM

ipn 0 M/M IPN - see Note 4

IPM

heading M M/M

this -IPM M M/M IPMIdentifier

originator 0 M/M ORDescriptor

author izing-users 0 0/M RecipientSpec if ier

primary- recipients 0 M/M RecipientSpecifier

copy- recipients 0 M/M RecipientSpeclf ier

blind- copy- recipients 0 0/M RecipientSpecif ier

replied- to- IPM 0 M/M IPMIdentifier

obsoleted-IPMs 0 0/M IPMIdentifier

related-IPMs 0 0/M IPMIdentif ier

subj ect 0 M/M See Note 1

,

8 expiry- time 0 0/M

reply- time 0 0/M

reply- recipients 0 0/M ORDescriptor

importance 0 0/M

sensitivity 0 0/M

auto - forwarded 0 0/M

extensions 0 0/M HeadingExtens ion

incomplete -copy 0 0/0

languages 0 0/M

body M M/M BodyPart

IPNcommon- fields M M/M

subj ect- ipm M M/M

ipn-originator 0 M/M ORDescriptor

ipm-preferred- recipient 0 M/M ORDescriptor

conversion-eits 0 0/M EncodedinformationTypes

non- receipt- fields 0 M/M See Note 5 non- receipt- reason M M/M

discard- reason 0 M/M

auto - forward- comment 0 0/M

returned- ipm 0 0/0 See Note 2 receipt-fields 0 0/M

receipt- time M M/M

8-37
December '

Interpersonal Messaging Protocol (P2) Part 2 of 3

Support by

UA

Protocol Element S 0/R Comments/References

acknowledgment -mode 0 0/M

suppl- receipt -info 0 0/0

HeadingExtension

type M M/M

value M M/M

IPMIdentifier

user 0 0/M

user- relative- identifier M M/M

ORDescriptor

formal -name 0 0/M ORName - see Note 3 free -form- name 0 0/M See Note 8

telephone -number 0 0/M

RecipientSpecifier

recipient M M/M ORDescriptor

notification- requests 0 0/M

reply- requested 0 0/M

BodyPart

ia5- text 0 M/M

parameters M M/M

repertoire 0 0/M See Note 6

data M M/M

voice 0 * See Note 7 g3-facsimile 0 0/0

parameters M M/M

number -of -pages 0 0/M

non-basic -parameters 0 0/M

data M M/M

g4-classl 0 0/0

teletex 0 0/0

parameters M M/M

number- of -pages 0 0/0

telex- compatible 0 0/0

non-basic -parameters 0 0/0

data M M/M

videotex 0 0/0

parameters M M/M

syntax 0 0/M

data M M/M

encrypted 0 * See Note 7

8-38
December '89

Interpersonal Messaging Protocol (P2) Part 3 of 3

Protocol Element

Support by

UA

0/R Comments /References

message

parameters

delivery- time

de 1 ivery - enve lope

data

mixed-mode

bilaterally -defined

nationally- defined

externally- defined

parameters

data

GeneralTextBodyPart

0/M

M/M

0/M

0/M

M/M

0/0

0/0

0/0

0/M

M/M

M/M

See P3 OtherMessage

DeliveryFields

Notes

1) The ability to generate the maximum size subject is not

required.

2) May only be included if specifically requested by the

originator

.

3) The ORNarae should be specified wherever possible.

4) The ability to generate an IPN is optional in the case of an implementation in which a non-receipt condition cannot

occur and receipt notification is not supported (see

table 8.5)

.

5) The ability to generate non-receipt-fields is optional in

the case of an implementation in which a non-receipt

condition cannot occur (see Note 4).

6) Only the IA5 repertoire has to be supported for an ia5-text

body part on reception.

7) The definition of these body parts is for further study in

CCITT and ISO.

8) Only the IA5 subset of the T.61 character repertoire need

be generated. All T.61 characters should be supported on reception.

8-39
December '89

8. 17.3 MTS Access Protocol (P3)

Note: The support classifications for the IPM UA, MS and MTA below

indicate the minimum level of support required by

implementations conforming to these Agreements, and should

not be misconstrued as a redefinition of any of the MHS

application contexts.

Table 8.27. Classification of the P3 Protocol Elements

MTS Access Protocol (P3) Part 1 of 10

Support by: T1 PMrfl UA

0/R

MS

0/R

MTA

Protocol Element S 0/R Comments/References

Operations

MTSBind

MTSUnbind

M

M

M/M M/M

yjf /\jf M/M

M/M

M/M

MTSBind

MSSE

message -submission

probe -submission

cancel -deferred- delivery

submission- control

M

M

M

M

M/-

0/-

0/-

-/M

M/M

M/M

M/M

M/M

-/M

-/M

-/M

0/-

MessageSubmission

ProbeSubmission

CancelDeferredDe livery

SubmissionControl

MDSE

mess age -de livery

report -de livery

de 1 ivery - contro

1

M

M

M

-/M

-/M

0/-

M/M

M/M

0/-

M/-

M/-

-/M

MessageDe livery

ReportDelive ry

DeliveryControl

MASE

register

change -credentials

(MTS to MTSuser)

(MTSuser to MTS)

M

M

M

0/-

-/M

0/-

M/M

M/M

M/M

-/M

0/-

-/M

Register

ChangeCredentials

ChangeCredentials

Note: A Message Store must pass

unaltered.

through all MSSE and MASE operations

8-40
December '89

MTS Access Protocol (P3) Part 2 of 10

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

Arguments/Results

MTSBind MTS to MTS User

ARGUMENT

initiator -name M -/M -/M M/-

mTS-user -/- -/- -/-

mTA 0 -/O -/M M/-

isMes sage Store -/- -/- -/-

messages -waiting 0 -/O -/O 0/-

initiator -credentials M -/M -/M M/-

simple 0 -/M -/M M/-

strong 0 -/O -/O 0/-

security -context 0 -/O -/O 0/- 1-256

RESULT

responder-name M M/- M/- -/M

mTS-user 0 M/- M/- -/M

mTA -/- -/- -/-

isMessageStore 0 M/- M/- -/M

messages -waiting -/- -/- -/-

responder- credentials M M/- M/- -/M

simple 0 M/- M/- -/M

strong 0 0/- 0/- -/O

MTSBind MTS User to MTS

ARGUMENT

initiator -name M M/- M/- -/M

mTS-user 0 M/- M/- -/M

mTA -/- -/- -/-

isMessageStore 0 M/M M/- -/M

messages -waiting -/- -/- -/-

initiator -credentials M M/- M/- -/M

simple 0 M/- M/- -/M

strong 0 0/- 0/- -/O

security- context 0 u/ 1-256

RESULT

responder-name M -/M -/M M/-

mTS-user -/- -/- -/-

mTA 0 -/M -/M M/-

isMessageStore -/- -/-

messages -waiting 0 -/O -/O 0/-

responder-credentials M -/M -/M M/-

simple 0 -/M -/M M/-

strong 0 -/O -/O 0/-

8-41
December '89

MTS Access Protocol (P3) Part 3 of 10

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

Message Submission

ARGUMENT

M M/- M/- -/M MessageSubmission

Envelope

contzent M M/-- M/- -/M

RESULT

mficQacTp- QiiHmi QQi on — i Hp"nt~i "Pi M -/M -/M M/- See PI MTSIdentif ier

mp^s^app 111^ *i9 h3 dL E.^> - u^tihim 1-/ 111 "iJ- s*?!J_ on-t"imp \^ L L ^ JL IIIV^ M -/M -/M M/-

content- identifier 0 -/M -/M M/-

extensions 0 -/O -/O 0/-

originating-MTA- certificate 0 -/O -/O 0/-

nt'riO'F-n'F - €;i ibm i q

q

i on 0 -/O -/O 0/-

ProbeSubmission

ARGUMENT

enve 1 one M M/- M/- -/M ProbeSubmission

Envelope

RESULT

probe-submission- identifier M -/M -/M M/- See PI MTSIdentifier

probe -submission- time M -/M -/M M/-

content- identifier 0 -/M -/M M/-

CancelDeferredDe livery

ARGUMENT

mpqcapp liL J U. E.^' - Qiibm L-/ til 1J- 's'jion-i ij A. \^ LI -1- dpnL 1 1 J.1 fJ_ iJ- p ri- M M/- M/- -/M See PI MTSIdentifier

Submiss ionControl

ARGUMENT

contro Is M -/M -/M M/- See Note 1 n -/M -/M 0/-

permissible -operations 0 -/M -/M 0/-

pe rmi s s ible- maximum -content

length 0 -/M -/M 0/-

permissible- lowest-priority 0 -/M -/M 0/-

permissible -security -context 0 -/O -/O 0/-

RESULT

waiting M M/- M/- -/M See Note 2 waiting- operations 0 0/- 0/- -/M 0-16

wa i t ing -messages 0 0/- 0/- -/M

waiting-content- types 0 0/- 0/- -/M 0-1024

waiting-encoded- information- See PI Encoded

types 0 0/- 0/- -/M InformationTypes

8-42
December '89

MTS Access Protocol (P3) Part 4 of 10

Support by: IPM

UA MS MTA

Protocol Element b 0/R 0/R 0/R Comments/References

Me ssageDe livery

ARGUMENT

envelope n - /M - /M M/- MessageDe liveryEnve lope

content n -/M -/M M/-

rec ipient- cer t i fi cate r\V 0/- 0/- -/O

prooL ot (le i. 1ve r

y

A\J 0/- 0/- -/O

ivcpo x7 L-jjexxvery

ARPTTMT7MT enve lope n.M -/M -/M M/- ReportDeliveryEnvelope

re turned- content U -/M -/M 0/-

De 1 iveryContro i AKGUnhilN i

y-t y-^ •»-> f" V* 1 O LIM M/- M/- -/M See Note 3

ire s L.L ic L o 0/- 0/- -/M

pcLlIliS S i- U Xc^ ope L cl U XUIlb 0/- 0/- -/M

permi s s

i

d j.e maximum concenc

length U 0/- 0/- -/M

permissible- lowest -priority 0 0/- 0/- -/M

permissible -content -types 0 0/- 0/- -/M

permi s s i. j.e encocicci See PI Encoded

information- types U 0/- 0/- -/M Informat ionTypes

permiss ible - security- context u 0/- 0/- -/O

D IT OTTT T" KtibULi

waiting M -/M -/M M/- See Note 4

wait ing- operations VJ -/M -/M 0/-

waiting -mess ages r\U -/M -/M 0/-

wait ing- content - types -/M -/M 0/-

wait ing- encoded- information- See PI Encoded

types 0 -/M -/M 0/- I nfo rmat i onType s

Register See Note 5 ARGUMENT

user -name 0 0/- 0/- -/O See X.411, 8.4.1.1.1.1

user-address 0 0/- 0/- -/O

deliverable-encoded- See PI Encoded

informat ion- types 0 0/- M/- -/M Informat ionTypes

deliverable -maximum- content

length 0 0/- M/- -/M

de faul t - de 1 ive ry -controls 0 0/- 0/- -/M

restrict 0 0/- 0/- -/M

8-43
December '89

MTS Access Protocol (P3) Part 5 of 10

Support by: T DM

TTA Uri illf\ MTA

Protocol Element S U/K U/K U/K Comments/References

permissible -operations 0 0/- 0/- - /M

permiss ible - maximum-content

length 0 0/- 0/- -/M

permissible- lowest -priority 0 0/- 0/- -/M

permiss ible -content- types 0 0/- 0/- -/M 1-1024

permissible-encoded- See PI Encoded

informat ion- types 0 U/- U/- -/M InformationTypes

deliverable -content -types 0 - /M 1-1024

labels -and- redirect ions 0 1-256 user- security- label 0 n /-

recipient- ass igned- al ternate

recipient 0 0/- 0/- -/O

ChangeCredentials MTS to MTSuser

ARGUMENT

old- credentials M - /M

simple 0 - /M - /M 0/-

strong 0 - /O - /O 0/- new- credentials M - /M - /M M /-

simple 0 - /M - /M 0/-

strong 0 -/O -/O 0/-

ChangeCredentials MTSuser to MTS

ARGUMENT

old- credentials M M /- M /- - /M

simple 0 n/- - /M

strong 0 0/- 0/- - /O new- credentials M M/- M/- - /M

simple 0 0/- 0/- - /M

strong 0 0/- 0/- - /O

Mes sage SubmissionEnve lope See Note 6

\J 1- ^ tL A. L LCL 1^ LlCXlll^ M M/- M/- -/M See PI ORName

original-encoded- information- See PI Encoded

types 0 M/- M/- -/M InformationTypes

content- type M M/- M/- -/M

built-in 0 0/- M/- -/M

external 0 0/- M/- -/M

content- identifier 0 0/- M/- -/M 1-16

priority 0 M/- M/- -/M All values

per -message- indicators 0 M/- M/- -/M

disclosure -of- recipients 0 0/- M/- -/M

8-44
March 1990 (Stable)

MTS Access Protocol (P3) Part 6 of 10

Support by: TPM J. LLl

TTA no ill MTAA

Protocol Element S \J/ IS. n /R nV^//RIS.

implicit- conversion-prohibited 0 M/- -/M/M

alternate -recipient- allowed 0 M/- M/- - /n/M

content- re turn- request 0 0/- M/- - /M

deferred-delivery- time 0 M/- M/- - /M

extensions 0 M/- M/- - /M

recipient- reassignmentprohibited 0 0/- M/- -/M

dl - expans ion-prohib i ted 0 M/- "/M/- - /M

conversion-with-lossprohibited 0 0/- n/M/- - /M

latest- del ivery - 1 ime 0 n/ - /n/M

originator- re turn- address 0 n/- M /- --/n/M

originator- certificate 0 n/- n/- - /n

content- confidentialityalgorithm- identifier 0 r> /- - /n

message -originauthentication- check 0 0/- 0/- - /O

message -security- label 0 0/- 0/- -/O

proof-of- submission- request 0 0/- 0/- -/o

content-correlator 0 0/- M/- -/M

forwarding- request 0 0/- M/- - /M MS Abstract Service only

PerRecipientMessageSubmission

Fields M M/- M/- - /M 1-32767

recipient -name M M/- M/- - /M See PI ORName

originator -report- request M M/- M/- - /M

explicit- conversion 0 0/- M/- - /M

extensions 0 M/- M/- - /M

originator-requestedalternate- recipient 0 0/- 0/-

reque s ted- de 1 ivery - me thod 0 M/- 11/ M/- - /M

physical-forwardingprohibited 0 0/- M/- -/M

phys ical- forwarding- address

request 0 0/- 0/-

phys ical -de livery-modes 0 0/- 0/- -/o

registered-mail- type 0 0/- 0/- -/o

recipient -number -for -advice 0 0/- 0/- -/o

phys ical -rendition- at tributes 0 0/- 0/- -/o

phys ical -delivery- reportrequest 0 0/- 0/- -/o

message - token 0 0/- 0/- -/o

content- integrity-check 0 0/- 0/- -/o

proof-of -de livery- request 0 0/- 0/- -/o

8-45
March 1990 (Stable)

MTS Access Protocol (P3) Part 7 of 10

Support by: TPM

TTA uri. MTA

Protocol Element S \J/ is. n\J//RIS. Comments/References

ProbeSubmissionEnvelope See Note 6

originator -name M n/- M /- - /M See PI ORName

original -encoded- information- See PI Encoded

types 0 M /- /ra InformationTypes

content- type M M/- M/- -/M

built-in 0 /ra 0-32767

external 0 u/ - M /- /ra

content- identifier 0 n/- M/- - /n/M 1-16

content- length 0 M/- M/- -/M 0-'7FFFFFF'H

per-message- indicators 0 M/- -/M

implicit- conversion-prohibited 0 M/- M/- - /ri /M

alternate -recipient -allowed 0 U/- n/- -/M

extensions 0 M/- M/- - /^i /M

recipient -reassignmentprohibited 0 nU/-/- -/ra

dl- expansion-prohibited 0 ra/ - /ra /M

conversion-with-lossprohibited 0 - /ra /M

originator -certificate 0

message -security- label 0 0/- 0/- - /O

content -correlator 0 - /ra /M

probe -origin- authenticationcheck 0 n/- 0/- - /o

PerRecipientProbeSubmission

r xe xus n M/- M/- - /n/M 1-32767

recipient -name M M/- M/- -/M See PI ORName

originator- report- request M M/- M/- -/M

explicit- conversion 0 n/M/- - /ra /M 0-256

extensions 0 - /ra /M

originator -reques tedalternate -recipient 0 n/- n /- - /o

reques ted- delivery-method 0 ra/- _-/ra /M 0-256

physical -rendition- attributes 0 u/- - /M

See Note 7

message-delivery- identifier M -/M -/M M/- See PI MTSIdentifier

message-delivery- time M -/M -/M M/-

other-fields M -/M -/M M/-

content- type M -/M -/M M/-

built-in 0 -/M -/M M/- 0-32767

external 0 -/M -/M M/-

originator-name M -/M -/M M/- See PI ORName

8-46
December '89

MTS Access Protocol (P3) Part 8 of 10

Support by: IPM

UA MS MTA

Protocol Element S 0/R 0/R 0/R Comments/References

original-encoded- information- See PI Encoded

types 0 -/M -/M M/- InformationTypes

priority 0 -/M -/M M/- All values

delivery- flags 0 -/M -/M M/-

implicit -conversionprohibited 0 -/M -/M M/-

other -recipient-names 0 -/M -/M M/- See PI ORName

this -recipient -name M -/M -/M M/- See Pi ORName

originally- intended-recipientname 0 -/M -/M M/- See PI ORName

converted-encoded- information- See PI Encoded

types 0 -/M -/M M/- InformationTypes

message -submission- time M -/M -/M M/-

content- identifier 0 -/M -/M M/- 1-16

extensions 0 -/M -/M M/-

conversion-with- lossprohibited 0 -/M -/M M/-

requested- delivery -method 0 -/M -/M M/-

physical-forwardingprohibited 0 -/M -/M M/-

phys ical - forwarding- addres s

request 0 -/M -/M M/-

phys ical -de livery -modes 0 -/M -/M M/- 0-16

registered- mail- type 0 -/M -/M M/- 0-256

recipient -number -for -advice 0 -/M -/M M/- 1-32

phys ical -rendition- at tributes 0 -/M -/M M/-

phys ical -de livery- reportrequest 0 -/M -/M M/- 0-256

originator- re turn- address 0 -/M -/M M/-

originator -certificate 0 -/O -/O 0/-

message- token 0 -/O -/O 0/-

content -confidentialityalgorithm- identifier 0 -/O -/O 0/-

content- integrity-check 0 -/O -/O 0/-

message -originauthentication- check 0 -/O -/O 0/-

message-security- label 0 -/o -/O 0/-

proof- of- delivery- request 0 -/O -/O 0/-

redirection-history 0 -/M -/M M/- 1-512

dl - expans ion-his tory 0 -/M -/M M/- 1-512

8-47
December '89

MTS Access Protocol (P3) Part 9 of 10

Support by: IPM

ITA HD MTA

Protocol Element S 0/R 0/R 0/R Comments/References

ReportDe liveryEnvelope See Note 7 subj ect- submission- identifier M - /M - /M ra/ See PI MTSIdentifier

content- identifier 0 - /ra /M ra/ content- type 0 - /M - /M M/-

built-in 0 - /M - /M M/- '•V 0-32767

external 0 -/M -/M M/-

original -encoded- information- See PI Encoded

types 0 - /M - /M M/- InformationTypes

extensions 0 - /M - /M M/-

message -security- label 0 - //O^ 0/-

content -correlator 0 - /M M/-

originator -and- DL- expansion- See PI OriginatorAndDL

history 0 - /M - /M M/- Exp ans i onH i s t o r

y

reporting-DL-name 0 - /M - /M M/-

reporting-MTA- certificate 0 - /O - /O 0/- ^/

report -origin- authenticationcheck 0 - /O 0/-

PerRecipientReportDe livery

Fields M - /M - /M 1-32767

actual -recipient -name M -/M - /M M/- See PI ORName

report M - /M - /M M/-

delivery 0 - /M - /M M/- mess age -de livery -time M -/M -/M M/-

type-of-MTS-user 0 -/M -/M M/- non- delivery 0 -/M -/M M/- non- delivery- reason- code M -/M -/M M/- ''1 non- delivery- diagnostic -code 0 -/M -/M M/-

converted- encoded- information- See PI Encoded

types 0 -/M -/M M/- InformationTypes

originally- intended- recipient

name 0 -/M -/M M/- See PI ORName

supplementary- information 0 -/M -/M M/- 1-256

extensions 0 -/M -/M M/-

redirection-history 0 -/M -/M M/- See PI Redirection

History, 1-512

physical -forwarding -address 0 -/M -/M M/-

recipient- certificate 0 -/O -/O 0/-

proof -of -delivery 0 -/O -/O 0/-

8-48
December '89

MTS Access Protocol (P3)

Notes

Part 10 of 10

1) The MTS-user may interpret any restriction as simply withhold

'all' submissions.

2) No explicit action needs to be taken by the MTA.

3) The MTA may interpret any restriction as simply withhold 'all'

deliveries

.

4) No explicit action needs to be taken by the MTS-user.

5) The Register operation may be performed locally (see X.411).

Although not required for the UA for conformance, it is

considered to be a useful service and support is recommended.

6) The action to be taken by a submitting MTA is as defined in

X.411 (ISO 10021-4). In the absence of any specific processing

requirements for a particular element in a submission envelope,

the action to be taken is simply the faithful mapping of such

element to the corresponding element of the appropriate transfer

envelope

.

7) The action to be taken by a delivering MTA is as defined in X.411

(ISO 10021-4) . In the absence of any specific processing

requirements for a particular element in a delivery envelope, the

action to be taken is simply the creation of such element from

the corresponding element of the appropriate transfer envelope.

8-49
December '89

8.17.4 MS Access Protocol (?7)

Table 8.28. Classification of the P7 Protocol Elements

MS Access Protocol (P7) Part 1 of 6

Support by: IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

Operations

MSBind M M/- -/M MSBind

MSUnbind M M/- -/M

MSSE

message -submission M M/- -/M See P3 MessageSubmission

probe -submission M 0/- -/M See P3 ProbeSubmission

cancel -deferred- delivery M 0/- -/M See P3 CancelDeferred

Delivery

submission- control M -/M M/- See P3 SubmissionControl

MASE

register M 0/- -/M See P3 Register

change-credentials (MS to UA) n See P3 ChangeCredentials

change-credentials (UA to MS) M 0/- -/M See P3 ChangeCredentials

MKbti

summarize M M/- -/M Summarize

list MJM M/- -/M List

le ten Sri M/- -/M Fetch

aeiete n M/- -/M Delete

regis ter-ms M 0/- -/M Register-MS

alert M -/O 0/- Alert

Arguments/Results

MSBind

ARGUMENT

MSBindArgument M M/- -/M

initiator -name M M/- -/M

initiator -credentials M M/- -/M

simple 0 M/- -/M

strong 0 0/- -/o

security -context 0 0/- -/O

fetch -restrict ions 0 0/- -/M

allowed- content -types 0 0/- -/M

allowed-EITs 0 0/- -/M

maximum- content - length 0 0/- -/M

MS -configuration- request 0 0/- -/M

8-50
December '89

MS Access Protocoi (P7) Part 2 of 6

Support by: IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

11M -/M M/-

re spender- credent ials n.M -/M M/-

simple U -/M M/-

s t rong -/O 0/-

available -auto -act ions U -/M M/- 1-16

available -attribute - types U -/M M/- 1-1024

alert- indication U -/M 0/-

content- types - supported u -/M M/-

Suimnar ize

SummarizeArgument n M/- -/M

information-base - type r\U 0/- -/M InformationBase

selector M M/- -/M Selector

ow 0/- -/M 1-16

SummarizeResult M -/M M/-

next 0 -/M M/-

count nM -/M M/- 0-'7FFFFFFF'H

span nu -/M M/-

XL* WC is L. M -/M M/-

highes

t

nM -/M M/-

summaries r\ -/M M/- 1-16 ausenc VJ -/M M/- 1-'7FFFFFFF'H

present nu -/M M/- 1- ' 7FFFFFFF'H

type -/M M/-

value ri -/M M/-

count -/M M/-

List

ARGUMENT

ListArgument M M/- -/M

information-base- type 0 0/- -/M InformationBase

selector M M/- -/M Selector

requested- attributes 0 M/- -/M At tributeSe lection

RESULT

ListResult M -/M M/-

next 0 -/M M/-

requested 0 -/M M/- Entryinformation

,

0- '7FFFFFFF'H

8-51
December '89

MS Access Protocol (P7) Part 3 of 6

Support by: IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

Fetch

ARGUMENT

FetchArgument M M/- -/M

information-base - type 0 0/- -/M InformationBase

item M M/- -/M

search 0 M/- -/M Selector

precise 0 M/- -/M

requested- at tributes 0 M/- -/M AttributeSe lection

RESULT

FetchResult M -/M M/-

entry- information 0 -/M M/- EntryInformation

list 0 -/M M/- 0-'7FFFFFFF'H

next 0 -/M M/-

Delete

ARGUMENT

De le teArgument M M/- -/M

information -base- type 0 0/- -/O InformationBase

items M M/- -/M

selector 0 M/- -/M Selector

sequence -numbers 0 M/- -/M 1-'7FFFFFFF'H

RESULT

DeleteResult M -/M M/-

Register-MS

ARGUMENT

Regis ter-MSArgument M M/- -/M

auto -act ion- registrations 0 0/- -/O 1-1024

type M M/- -/M

registration- identifier 0 M/- -/M

registration- parameter M M/- -/M See auto action

registration parameters

auto -act ion- deregistrat ions 0 0/- -/O 1-1024

type M M/- -/M

registration- identifier 0 M/- -/M

list -at tribute -de faults 0 M/- -/M 1-1024

fetch- attribute -de faults 0 - /ra /M 1-1024

change -credentials 0 M/- -/M

old -credentials M M/- -/M new- credentials M M/- -/M user- security- labels 0 0/- -/O 1-256

RESULT

Regis ter-MSResult M -/M M/-

8-52
December '89

MS Access Protocol (P7) Part 4 of 6

Support by: IPM

UA MS

Protocol Element S (J/K (J/K Comments/References

Alert

AKbUMhjN i AlertArgument M -/M M/-

alert- regis trat ion- identifier M -/M M/- new- entry 0 -/M M/- EntryInformation

RESULT

AiertKesui

t

U M/- -/M

Auto Action Registration

Parameters

AutoForwardRegis trat ionParameter

filter 0 0/- -/M Filter

auto - forward- arguments M M/- -/M

originator -name M/- -/M

content- identifier (J 0/- -/M

priority U 0/- -/M

per -mess age - indicators V 0/- -/M See P3

deferred- delivery -time 0 0/- -/M

extensions 0 0/- -/M See P3

per - recipient - fields n. M/- - /M

recipient -name M M/- -/M

originator -report -request rl M/- -/M

explicit- conversion r\U 0/- -/M

extensions U 0/- -/M See P3

de le te - after - auto - forwarding 0 0/- -/M

other -parameters 0 0/- -/M See Note L auto - forwarding- comment 0 0/- -/M

cover-note 0 u/ - - /M

this- ipm-prefix 0 0/- -/M

AutoAlertRegis trat ionParameter

filter 0 0/- -/M Filter

alert -addresses 0 0/- -/O

address M M/- -/M

alert- qualifier 0 0/- -/O

requested- at tributes 0 0/- -/M Attributes elect ion

Notes

1) The specified syntax of other -parameters is for IPMS use only - see X.413 clause 12.1 and X .420 clause 19.4.

8-53
December '89

MS Access Protocol (P7) Part 5 of 6

Support by: IPM

UA MS

Protocol Element S 0/R 0/R Comments/References

Common Data Types

At tributeSe lection

type M M/- -/M

from 0 0/- -/M 1-32767

n 0/- -/M 1-32767

AttributeValueAssertlon

type M M/- - /M

value M M/- -/M

ULlL-i-y t~ T*"\7Ti. TilH~\Jcifm^ L Ilia t"\^ 1J-WonLl sequence -number M -/M M/-

attributes 0 -/M M/- 1-1024

type M - /M M/-

values M -/M M/-

Filter

item 0 M/- -/M Filterltem

and 0 0/- -/o 1-32 or 0 0/- -/O 1-32 no t 0 0/- -/o

Filterltem

equality 0 M/- -/M AttributeValueAssertlon

(Support is 0 if ORname)

c 1 1}-) c t" r 1 n P s 0 0/- -/o

type M M/- -/M

strings M M/- -/M

greater -or -equal 0 0/- -/M AttributeValueAssertlon

less-or-equal 0 0/- -/M AttributeValueAssertlon

present 0 0/- -/M

InformationBase

stored-messages 0 M/- -/M

inlog 0 0/- -/O

outlog 0 0/- -/O

Range

sequence -number - range 0 0/- -/M

from 0 0/- -/M

to 0 0/- -/M

8-54
December ' 89

MS Access Protocol (P7) Part 6 of 6

Support by: IPM

UA

0/R

MS

Protocol Element S 0/R Comments/References

creation- time - range

from

to o

o

o 0/-

0/-

0/-

/M -/M

-/M

-/M

Selector

child-entries

range

filter

limit

override

0

0

0

0

0

0/-

0/-

0/-

0/-

0/-

-/M

-/M

-/M

-/M

-/M

Range

Filter

8-55
December '89

8.17.5 Message Store General Attribute Support

Table 8.29. Classification of the Message Store General Attributes

Message Store General Attribute Support Part 1 of 2

Support by: IPM

UA

Rec

Bas

MS

Org

IPM

MS

Attribute S Org Comments/References

child- sequence -numbers M M M M

content n M M M

content- confidentialityalgorithm- identifier U U U

r\U

content -correlator 0 U U rl content- identifier (J U u MM

content- integrity-check 0 0 0 0

content- length 0 U U M

content -re turned 0 0 0 M

content- type M M M M

conversion-with- loss -prohibited 0 0 0 M

converted- eits 0 0 0 M

creation- time M M M

delivered- eits r\U 0 0 M

de 1 ivery- flags r\U U M

dl- expansion-history 0

r\U U

Kfn. entry- status M M 11M 11M

entry type M M

Uln M

intended- rec ip lent -name U (J U M

me s s age - de 1 ivery - enve lope M M iMI 11M

message-delivery- identifier U U U me s s age - de 1 ive ry - 1 ime 0 0 0 n mess age -origin- authenticationcheck 0 0 0 U

message -security- label 0 u U

r\U mess age -submission- time 0 0 0 n message- token 0 0 0 u original-eits 0 0 0

\tn originator -certificate 0 0 0 0

originator -name 0 0 0 M

other -recipient -names 0 0 0 M

parent -sequence -number M M M M

per -recipient -report -de livery

fields M M M M

priority 0 0 0 M

proof -of -de livery -request 0 0 0 0

redirection-history 0 0 0 M

registration- indication 0 0 0 0

report- del ivery- enve lope M M M M

report ing-dl -name 0 0 0 0

reporting-mta- certificate 0 0 0 0

8-56
December '89

Message Store General Attribute Support Part 2 of 2

Support by: IPM

UA

Rec

Bas

MS

Org

IPM

MS

Attribute S Org Comments/References

report -origin- authenticationcheck

security- classification

s e quence - numbe

r

subj ect- submission- identifier

this -recipient-name

0

0

M

M

0

0

0

M

M

0

0

0

M

M

0

0

0

M

M

M

Note: Enhanced MS support for optional Functional Groups is for further

study. Attributes which are relevant to these areas are currently

specified as Unsupported.

8-57
December '89

8.17.6 Message Store IPM Attribute Support

This section is to be read in accordance with Annex C of X.420 (1988).

Table 8.30. Classification of the Message Store IPM Attributes

Message Store IPM Attribute Support Part 1 of 2

Support by: T PM

D ^ ^ Kec

Ti PMrii

Attribute S Org Comments/References

Summary Attributes

ipm-entry- type (J U

MM

1pm- synopsis 0 U M

neaaing AttriDutes

.

aucnor Lz ing users n U auco lorwaraeci r\\} U rl D J. inci copy recxpiencs nu U M

copy- recipients u U 11M

expiry- time U n.M

heading M M M

importance 0 U rl incomplete -copy 0 0 0

languages U 0 M

nrn- requestors 0 0 M

obsoleted- ipms u U M. ongmauor U u n

pi imaLy recipxents u U

Mn. related- ipms 0 U rl replied- to- ipm 0 u n. reply- recipients 0 0 M

reply- requestors 0 0 M

reply- time 0 0 M

rn-requestors 0 0 M

sensitivity 0 0 M

subj ect 0 0 M

this- ipm M M M

Body Attributes:

b i lateral ly-defined-bodyparts 0 0 0

body M M M

encrypted-body -parts 0 0 0

encrypted- data 0 0 0

encrypted -parameters 0 0 0

extended-body-part- types 0 0 0

8-58
September 1990 (Stable)

Message Store IPM Attribute Support Part 2 of 2

Support by: TPM

UA

DK.ec A

TPM

1 LiJ Attribute urg oommencs/Kexerences

py-^ CL\^ J A. HI X X^ UKJKXy Lldi. L.

O

o 0 0

O" ^ — TA OGTTni 1a — Hiat"a n nw o\j

r\\j o n

KJ j-d^ ccxt. Dooy parts r\U w M

ow n

1 P S — t"AVf~— TiaT*JiniA'f~AVG n mA c c S3 0*0 — r^/^/^'\^ — T^Ql^'t~o Mi 1 TTies s A p'A - fi;it~a 0 n

ine s s a p" A - "D arAni A t" A T Q 0 nw

TTIT VaH—TDoHa — VioHv — TiaT"t*G o\J 0 0

nationally- defined-body-parts 0 0 0

teletex-body-parts 0 0 0

[.c i.c ccA aaca KJ 0 0

UCi.C?L.t?A LF Ct 1. dliiC I. C X. o w 0 0

\T1 o V — r\rt /1\r — Q f" e u Vlaeo cex aaca u w

rj\j vyj i.\^xi u\j u> y LI ct I. L. o u voice -data 0 w

Nnf"i 'Fi pfl t" 1 on Af"l"T"i hiit"<=>e!

\I \r -1. 1- A. ^ d XV1 i ii ^ X. X U U ^ O . acknowledgment -mode 0 0 M

auto - forward- comment 0 0 M

conversion-eits 0 0 M

discard- reason 0 0 M

ipm-preferred- recipient 0 0 M

ipn- originator 0 0 M

non- receipt- reason 0 0 M

receipt- time 0 0 M

returned- ipm 0 0 0

subject-ipm M M M

suppl-receipt- info 0 0 0

8- 59
September 1990 (Stable)

8. 18 APPENDIX B: INTERPRETATION OF ELEMENTS OF SERVICE

See Working Document.

8-60
December ' 89

8.19 APPENDIX C: RECOMMENDED PRACTICES

This section provides guidelines on areas not addressed by the base

standards. These guidelines have been produced in order to promote

awareness of interim solution to problems as agree by members of the

NIST X.400 SIG. However implementors of these recommended practices

should note that it is not necessary to follow the recommended

practices when claiming conformance to these agreements.

Implementors should also note that future standardization by CCITT and

ISO/IEC on area covered by this section may result in different

solutions to those proposed in this section.

8.19.1 Printable String

There are existing mail systems that include a small set of non- Printable String characters in their identifiers. For these

systems to communicate with MHS systems, either for pass -through

service or delivery to MHS users, gateways will be employed to

encode these special characters into a sequence of Printable

String characters. This conversion should be performed by the

gateway according to a common scheme and before insertion in

Domain Defined Attributes, which are intended to carry electronic

mail identifiers. MHS UAs may also perform such conversions.

It is recommended that the following symmetrical encoding and

decoding algorithm for non-Printable String characters be

employed. The encoding algorithm maps an ASCII representation to a PrintableString representation. Any non-printable string

characters not specified in table 8.31 are covered by the

category "other."

Table 8.31. Printable string to ASCII mapping

ASCII Character Printable String Character

% (percent) (P)

(a (at sign) (a)

! (exclamation) (b)

" (quote mark) (q)

(underline) (u)

( (left paren.

)

(1)

) (right paren.

)

(r)

other (3DIGIT)

where 3DIGIT has the range 000 to 377 and is interpreted as the octal

encoding of an ASCII character.

8-6i
December '89

To encode an ASCII representation to a PrintableString , the table and

the following algorithm should be used:

IF current character is in the encoding set THEN

encode the character according to the table above

ELSE

write the current character;

continue reading;

To decode a PrintableString representation to an ASCII

representation, the table and the following algorithm should be used:

IF current character is not "(" THEN

write character

ELSE

{look ahead appropriate characters

;

IF composite characters are in the above table THEN

decode per above table

ELSE

write current character;

) continue reading;

8 . 19 2 Rendition of lASText

The characters that may be used in an lASString are the graphic

characters (including Space), control characters and Delete of

the IA5 character repertoire ISO 646.

The graphic characters that 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 (LP)

,

0/12 (FF) and 0/13 (CR) provided they are used in one of the

following combinations as defined in table 8.32.

8-62
December '89

Table 8.32. Interpretation of Format Effector Combinations

Combination Interpretation

CR LF

CR FF

LF . . LF

to start a new line

to start a new page (and line)

to show empty lines (always after one of the

preceding combinations)

.

The other control characters or the above control characters in

different combinations may be used but have no guaranteed effect.

The character Delete may occur but has no guaranteed effect. The

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

8.19.3 EDI Use of MHS

8.19.3.1 Introduction and Scope

This section presents a carry- forward of the Recommended

Practices in chapter 7 of the NIST Stable Implementation

Agreements for support of EDI data transfer in an MHS (1988)

environment. These recommended practices outline an interim

procedure for use in transferring EDI transactions between

trading partner applications in order to facilitate further

MHS implementation by EDI users. It is the stated

objective of the NIST X.400 SIC to migrate towards the CCITT

target solution of PgDi once it is defined (currently

expected to be completed by late 1990) . The approach for

carrying EDI interchanges over MHS systems as recommended in

this section provides a mechanism for a smooth migration to

the target CCITT P^di solution.

The scope of this guideline is to describe specific

recommended practices for extending MHS as a data transfer

mechanism between EDI applications. This interim solution,

as in the existing X. 400(1984) Agreements, is referred to as the PO approach and differs slightly from the European

solution which uses a P2 mechanism to package the EDI data

stream. However, if adhered to, PO messages may be

delivered to P2 recipients and vice -versa, by the MTA making

a minor envelope conversion as recommended in this section.

8-63
December '89

8.19.3.2 Model

The model used is consistent with that defined in section

7.12.5 of the Agreements for X. 400(1984) systems, with

several minor exceptions. As before, the model provides for

a peer-to-peer EDI Messaging (EDIM) UA service.

EDI User

Application

EDIM

UA

MTS EDIM

UA

EDI User

Application

Figure 8.11. EDI Messaging Functional Model.

In figure 8.11, the EDIM UA may support delivery of EDI

messages formatted according to the NIST P0(88) , P0(84),

P2(84) or P22(88) Agreements. It is recommended that

implementations supporting EDI over MHS generate PO

formatted messages as described below, but be prepared to

deliver any of the four recognized formats for which

Agreements have been achieved. Whether the EDI transaction

is carried using the PO or P2 (88 or 84) approaches, the EDI

content is restricted to be only one EDI interchange per MHS

message. The NIST approach carries forward the 1984 X.400

recommended practices as a interim interworking solution.

The use of object identifiers in either the EIT or Content

Type fields is not recommended due to the current definition

of the 1984 interworking rules specified in CCITT

Recommendation X.419 (see below).

The EDIM UA must support the essential MT and MS Elements of

Service as defined in this Agreement. It is recognized that

a Message Store may not convey much information to a remote

EDIM UA with the PO approach. It is further recognized that

MS Elements of Service are not necessarily made available by

the EDIM UA to the EDI user application.

8.19.3.3 Protocol Elements Supported for EDI

The following PI protocol elements will be used as a minimum

to support EDI applications:

Content Type

8-64
September 1990 (Stable)

For EDIM applications, the content type will continue to be

as specified in section 7.12,5.3 of the NIST Stable

Agreements for X. 400 ( 1984) , i.e., Undefined (0). The

interchange contained in the PI envelope and identified by

this Content Type is carried as an octet string.

Note: For interworking with 1984 X.400 systems, the use of an externally registered object

identifier is not recommended. Such use would

create interworking problems as well as loss of

information when the Z.419 downgrading rules are applied. In the current definition of the

latter, an object identifier would be mapped to

the Content Type value of 1 (External) , instead

of 0 (Undefined), Additionally, the

downgrading rules require the object identifier

value to be inserted into the Content, which

would cause further interworking problems since

1984 EDIM UAs will expect only the EDI

interchange in the Content,

Ori ginal Encoded Information Types (EITs)

EDIM applications will continue to use the EITs as specified

in section 7,12.5.3 of the NIST Stable Agreements for

X. 400(1984), i.e,, lASText and Undefined (for EBCDIC

encoding). However, it is recognized that any EIT defined

in the 1988 MHS standards may be used to specify the

encodings of the EDI content.

Note: For interworking with 1984 X,400 systems, the use of an externally registered object

identifier to signify the EDI encoding is not

recommended. According to the current

definition of the downgrading rules in CCITT

Recommendation X.419, a 1988 MTA must downgrade

an object identifier to Undefined and then

discard the object identifier. Such loss of EDI

encoding information conflicts with the existing

Agreements for X. 400(1984) systems that the

semantics of the Undefined EIT is always EBCDIC.

8.19.3.4 Addressing and Routing

As in the Stable Implementation Agreements for X, 400(1984),

EDI messages entering a 1988 MHS environment will need to

have MHS 0/R Names and/or 0/R Addresses in the PI envelope

to identify the originator and recipient trading partners.

The mapping of the EDI originator and recipient interchange

8-65
September 1990 (Stable)

addresses to an 0/R Name or 0/R Address may be achieved

either by local means or through services provided by the

OSI Directory (see sec. 8.9.1).

If the EDI message is originated and delivered without

transiting a X. 400 (1984) MTA, then any of the 0/R Address

forms specified in this Agreement may be used. However,

since it cannot be assumed that EDI messages will never

transit an X. 400(1984) MTA, it will often be useful to

include additional Domain Defined Attributes as specified in

section 7.12.5.4 of the Stable Agreements. This DDA is

needed to ensure that a message is deliverable to an EDIM UA

associated with a X. 400(1984) MTA and that delivery and

receipt reports can be flagged as a new report type.

8.19.4 Textual Representation of 0/R Names

I See Working Docuxnent

.

8.20 APPENDIX D: LIST OF ASN.l OBJECT IDENTIFIERS

I See Working Document.

8 . 20 1 Content Types

I See Working Document.

8.20.2 Body Part Types

I See Working Document.

8- 66
December '89

9_^ ISO FILE TRANSFER. ACCESS AND MANAGEMENT PHASE 2

Editor's Note: In document type names, constraint set names, and

abstract syntax definitions, the "NBS" designation

will be preserved.

9.1 INTRODUCTION

This section defines Implementors ' Agreements based on ISO File

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

International Standard has four parts. Part 1 of the IS gives

general concepts. Part 2 defines the Virtual Filestore (VFS) , Part 3 defines the File Service, and Part 4 defines the File Protocol.

FTAM, as described in the IS, is based on the following ISO documents:

ACSE Service and Protocol (ISO 8649, ISO 8650), Presentation Service

and Protocol (ISO 8822, ISO 8823), ASN.l Abstract Syntax Notation and

Basic Encoding Rules (ISO 8824, ISO 8825), and Session Service and

Protocol (ISO 8326, ISO 8327). These services and protocols are defined architecturally in the OSI Reference Model (ISO 7498). These

Agreements provide detailed guidance for the implementor, and

eliminate ambiguities in interpretations.

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

Access and Management Protocol (FTAM) are that the Phase 2 FTAM

specification (this sec.) is based on the International Standard

(IS).

9 . 2 SCOPE AND FIELD OF APPLICATION

These FTAM Phase 2 Agreements cover transfer of and access to files

between the Filestores of two end systems, including the management of

a Virtual Filestore. One end system acts in the Initiator role and

initiates the file transfer/access, while the other end system acts in

the Responder role and provides access to the file in the Virtual

Filestore. This paper describes Agreements for the actions and

attributes of the Virtual Filestore, and the service provided by the

file service provider to file service users, together with the

necessary communications between the Initiator and Responder.

9-1
December '89

Virtual

Filestore

2

Real

Filestore

1

End

System 1

- Initiator -

End

System 2

- Responder -

Real

Filestore

2

Figure 9.1. Model of file transfer/access.

Note: Agreements apply on the double lines of figure 1. T h e mapping between the Virtual Filestore and the Real

Filestore together with the local data management

system is not part of these Agreements

.

These Agreements define General Agreements in section 9.5 through

9.16, minimum functionality (Conformant Implementations) in section

9.17, and functionality for several Implementation Profiles which are tailored to different classes of user requirements in sections 9.18

and 9.19.

9.3 STATUS

Version 2 of the FTAM Phase 2 Implementation Agreements was completed

December 16, 1988, and published in version 2 of the Stable

Implementation Agreements (NIST Special Publication 500-162, December

1988). Some editorial clarifications, technical changes and alignment

changes (due to international harmonization of Profiles) were added to

Version 2 Agreements in the course of 1989. All these changes are now

fully incorporated in this version 3 of the FTAM Phase 2 Stable

Agreements

.

No further enhancements will be made to this version 3 of FTAM Phase

2 (see the next sec. ERRATA).

This version 3 of the FTAM Phase 2 Agreements fully replaces the

version 2 as published in NIST SP 500-162. Therefore, the old version

2 of FTAM Phase 2 will no longer be maintained.

9-2
March 1990 (Stable)

The following list summarizes the technical errata changes to FTAM

Phase 2, Version 1 which were incorporated in Version 2. It also

states the degree of possible interworking and backward compatibility

to FTAM Phase 2, Version 1.

Technical Changes in FTAM Phase 2,

Version 2 (Dec. '88)

1. Check of already established

presentation contexts for a document type not at CREATE

time but at OPEN time

2. Receivers shall not require

sending of AETtitles

3 . Minimum requirement for FADU

identities for document types

which use the sequential flat

constraint set

Backward Compatibility to FTAM

Phase 2, Version 1 (Dec. '87)

Interworking problems could

occur when creating a document type which is not

opened.

Inteirworking problems could

occur if AETitles are not

sent

Interworking problems could

occur if FADU identities

beyond the minimum requirement

are used

9-3
March 1990 (Stable)

The following list sununarizes the technical errata and alignment

changes which were incorporated in FTAM Phase 2, Version 3. It also

states the degree of possible interworking and backward compatibility

to FTAM Phase 2, Version 2.

Technical Changes in FTAM Phase 2,

Version 3 (Dec. '89)

Backward Compatibility to FTAM

Phase 2, Version 2 (Dec. '88)

Unconstrained Service Class

outside the scope of the

Implementation Profiles.

<contents- type -lis t> parameter:

Both types of values optional

for Initiators

Specification of supported

values for <override>

parameter in F- CREATE

Parameters <filesize>, <future

files ize>, <fadu-number> may be

encoded with up to 8 contents

octets

For NBS-7 and NBS-8 in

conjunction with T or TM

Service Class, the FADU

identities "current," "next,"

"previous" are not required

For NBS-8 files the minimum

range for keys of string- type

is (1-16) instead of (0-16)

Restriction "NBS-9 files may

not be Created or Deleted"

removed from the document type

definition. But both actions

are outside the scope of the

Agreements

.

Constraint set NBS-orderedflat: The location after an Insert is "end"

ProftlesT Full compatibility,

since change only from

"optional" "to "outside scope''

Full compatibility, since this

clarification is only for

Initiators

Interworking problems may

occur, if different values

supported

Interworking problems may

occur, since no minimum

requirement was defined for

Version 2.

Full compatibility, since

these identities were never

useful in conjunction with T

or TM Service Class

Interworking problems may

occur for key- length parameter

0.

Full compatibility, since

Creation, Deletion was never

in the scope of the Agreements

Full compatibility, since this

specification was already

implicitly clear

9-3-1

June 1990 (Stable)

9.4 ERRATA

Editor's Note: ERRATA applicability information may be given here.

REFERENCED

NO . OF ERRATA TYPE DOCUMENT SECTION

CP 3/90-1 TECHNICAL NIST-SP APPENDICES NBS-6, NBS-7,

500-177 A, B, C NBS-8, NBS-9,

NBS-ASl, NBS-AS2,

NBS -ordered- flat

constraint set

with Obj . Id.

using icd(9999)

withdrawn.

Above FTAM objects

newly defined with

Obj . Id. using

oiw(14) ftamsig(5)

CP 3/90-2 EDITORIAL 9.17.9 Clarification that

INTEGER encoding

of more than 4

contents octets may

be rejected by

receiver

CP 3/90-3 EDITORIAL Appendices instead

of section 9.21,

structuring into

subsections. All

references to these

definitions updated

accordingly

CP 3/90-4 EDITORIAL 9.3 New interworking

table for Phase 2,

Version 1 and

Version 2

CP 6/90-1 EDITORIAL 9.1 Notes 7 , 8 added

to clarify the use of Escape

Sequences

September 1990 (Stable)

9_Ji ERRATA

Editor's Note: ERRATA applicability information may be given here.

NO OF ERRATA TYPE

REFERENCED

DOCUMENT SECTION

CP 1 /QD 1 TPT'UMT r AT NIST-SP

500-i77

APPENDICES

A, B. C

NBS-6, NBS-7,

NBS-8, NBS-9,

NBS-ASl, NBS-AS2,

NBS- ordered- flat

constraint set

with Obj . Id.

using icd(9999)

withdrawn.

Above FTAM objects

newlv defined with

Obj . Id. using

oiw(14) ftamsig(5)

CP 3/90-2 EDITORIAL 9.17.9 Clarification that

INTEGER encoding

of more than 4

contents octets may

be rejected by

receiver

CP 3/90-3 EDITORIAL Appendices instead

of section 9.21,

^ tnif turi n P into

subsections. All

references to these

definitions updated

accordingly

CP 3/90-4 EDITORIAL 9.3 New inter\<7orking

table for Phase 2,

Version 1 and

Version 2

CP 6/90-1 EDITORIAL Table 9.1 Notes 7 , 8 added

to clarify the use of Escape

Sequences

9-4
December '89

9.5 ASSUMPTIONS

1. FTAM protocol machines must be able to parse and process at a minimum 7K octets of FTAM PCI, FTAM structuring (FTAM-FADU) and

FTAM user data (including grouped FPDUs) as they would be encoded

with the ASN.l Basic Encoding Rules. It is recommended, hov/ever,

that Presentation user data not be restricted in size.

2. In order to maximize interoperability, it is important that the

implementations of FTAM service providers do not unnecessarily

restrict the service user's ability to generate arbitrary file

service requests. Otherwise, they may not be able to work with

FTAM Responders whose operation is constrained by their mapping

of the FTAM Virtual Filestore to their local filestore. For

example, error procedures should only be invoked when an error actually occurs, not at the point of the specification of

options which might result in an error,

3. Implementations must be able to parse all valid optional

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

parameters specified as supported in these Agreements are required to be implemented. If 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 supported in these Agreements, is not

present.

4. Consideration of any standardized service interface is not

covered by these Agreements

.

5. These Agreements define no restrictions for the values used for

the <communication quality of service> parameter in <FINITIALIZE>.

6. FTAM is defined in phases. The Phase 1 FTAM implementation

specification is based on the second ISO Draft Proposal, dated

April 1985, and the ISO Draft Proposal 8824 and 8825.

The Phase 2 FTAM specification (this sec.) is based on the

International Standard (IS). THERE IS NO BACKWARD COMPATIBILITY

WITH NIST FTAM PHASE 1. Backward compatibility is impossible,

since Phase 1 uses Session services directly, while Phase 2 uses ACSE and Presentation services. Furthermore, there are differences in Filestore, PDU Abstract Syntax, FADU Abstract

Syntax, and Transfer Syntax. There also are differences in the

transparency mechanisms and service class negotiations.

The <implementation information> parameter of <F-INITIALIZE> FPDU

as defined in ISO 8571-4, 20.3 is used to pass 'user version'

information with respect to different FTAM phases of the NIST

Implementors Agreements or with respect to FTAM profiles of other

bodies (see sec. 9,12 of this document). It is the goal of

9-5
December '89

these Agreements to use the 'user version' mechanism to provide

at least one level of backward compatibility for all future

NIST FTAM Phases, facilitating backward compatibility for future

FTAM products, assuming different new versions of the respective

IS's also enable backward compatibility.

7. The FTAM specific ASE requirements for ACSE in the Upper Layers

chapter of this document define a value (that carries no semantics) for the AETitle that can be used by FTAM ASEs for

communication. Other values for the AETitle are outside the

scope of these Agreements.

The association shall not be rej ected/aborted if any of the

following parameters either contains the defined value or is not

sent:

Called - AETitle

Calling - AETitle

Responding - AETitle

The association may be rejected/aborted if any of these

parameters contain other values.

Use of values outside the scope of these Agreements is

discouraged until agreed upon semantics have been associated with

AETitles

.

8 . Use of <shared ASE information> parameter and <charging>

parameter is not defined within the scope of the Agreements

.

9. Use of <application context name> parameter is not defined within

the scope of these Agreements. This parameter does not prohibit

the establishment of an FTAM association.

10. These Agreements use the term 'supported' for a parameter to mean

that the syntax and semantics of that parameter shall be

implemented. However, it is not a requirement that the parameter

be used in all instances of communication, unless stated

otherwise

.

Also these Agreements use the term 'optionally supported' for a parameter to mean that it is left to the implementation whether

the semantics of that parameter are implemented or not.

9-6
March 1990 (Stable)

9.6 PRESENTATION AGREEMENTS

The following Abstract Syntaxes are recognized in these agreements:

"FTAM FADU"

"FTAM PCI"

"FTAM unstructured text abstract syntax"

"FTAM unstructured binar}'' abstract syntax"

"NBS abstract syntax ASl"

"NBS file directory entry abstract S3mtax"

The following Transfer Syntax is supported:

"Basic Encoding of a single ASN.l type"

(See Appendix C Part -3)

9.7 SERVICE CLASS AGREEMENTS

Implementation Agreements have been reached for the following service

classes

.

o File Transfer

o File Access

o File Management

o File Transfer and Management

o Unconstrained

9.8 FUNCTIONAL UNIT AGREEMENTS

Implementation agreements have been reached for the following

functional units.

o Kernel

o Read

o Write

o File Access

o Limited File Management

o Enhanced File Management

o Grouping

Implementation of the Recovery, Restart Data Transfer, and FADU

Locking functional units is not specified.

9.9 FILE ATTRIBUTE AGREEMENTS

Implementation of the Kernel Group of file attributes is defined. If

the optional Storage Group and Security Group are implemented,

aspects of their implementation are defined. Implementation of the

Private Group is not specified.

9-7
March 1990 (Stable)

Responses to an attribute value request shall always include one of

the following (as specified in ISO 8571-2, Clause 9.4):

o An actual file attribute value.

o A value indicating that no value is available, optionally with a diagnostic

.

o No value and an error code, optionally with a diagnostic

indicating that the attribute is not supported.

9.9.1 Mandatory Group

Only the Kernel Group of attributes is required. A value for

<filenanie>, <permitted actions>, and <contents type> will always

be available.

A minimum range is required for <filename> values as specified

in ISO 8571-2. No maximum length or format restrictions apply.

A system that does not support <filename> values with a sequence

of more than one Graphic String or extended <filename>

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

value with a sequence of one Graphic String,

A Responder shall not require an Initiator to use multiple

component Graphic String filenames. Requests using a single

component <filename> value with a sequence of one Graphic String

shall be responded to using a single component <filename> value.

Responses to requests involving <filename> values having two or more Graphic Strings are not defined here but may be interpreted

via bilateral or other external agreements. Use of <filename>

values with a sequence of more than one Graphic String is

discouraged.

Apart from the minimum conformance requirements specified in ISO

8571-2, file names have to be specified in the naming convention

of the responding FTAM implementation. It is a local

implementation matter of the FTAM Responder, whether or not an additional name mapping onto the real Filestore's file name

convention is supported.

In order to enable interworking with all FTAM Responders'

virtual Filestores, it is recommended that FTAM Initiators

impose no restrictions on the attribute range supported for file

names beyond those specified in ISO 8571-2.

For the purpose of interworking according to these Agreements the

9-8
June 1990 (Stable)

<contents type> attribute is limited to the <docuinent type name>

format. The <constraint set name, abstract syntax name> form is

outside the scope of these Agreements. It should always be

parsed correctly when received, but may result in an error.

9.9.2 Optional Groups

If the optional Security Group of file attributes is

implemented, an actual value must be available for the <access

control> attribute.

The <access control> attribute is a SET OF <access control

element>. The minimum requirement in these Agreements is the

support of one <access control element>, according to the base

standard. The terms <concurrency access>, <identity>, and

<passwords> are each optionally supported. Details of their use

shall be specified in the PICS. Use of the <location> term is

not specified in these Agreements.

Implementation of the Private Group is not specified.

9.10 DOCUMENT TYPE AGREEMENTS

These document types are defined.

FTAM-1 "ISO FTAM unstructured text"

FTAM-2 "ISO FTAM sequential text"

FTAM-3 "ISO FTAM unstructured binary"

NBS-6 "NBS-6 FTAM sequential file"

NBS-7 "NBS-7 FTAM random access file"

NBS-8 "NBS-8 FTAM indexed file"

NBS-9 "NBS-9 FTAM file directory file"

Detailed document type definitions are given in Appendix A and in ISO

8571-2, Annex B.

Note: Document types NBS-1 to NBS-5 are not defined in these

Agreements. The numbering starts with NBS-6 because of the

original DIS version of these Agreements.

An implementation claiming conformance to these Agreements which also

supports any or all of the document types FTAM-1, FTAM-2, and FTAM-3

as defined in ISO 8571-2, Annex B, must minimally support the

combinations of parameter values as specified in table 9.1.

9-9
June 1990 (Stable)

Table 9.1. Parameters for FTAM-1, -2, -3

Universal

1 Q G Ni 1 m)^ p f

Maximum String

Si trni fi pance

FTAM- 1 General String ^(27)

IA5String 2(22)

134 or less 'not-significant'

FTAM- 2 Graphic String ^'^(25) 134 or less^ 'not-significant'^

FTAM- 3 <not applicable> 512 or less 'not-significant^

Notes: 1. The minimum level of support for General String is the ISO

646, IRV GO character set and the 8859-1 GO and Gl

character sets, and ISO 646, IRV CO set.

2. The support for IA5 String is the ISO 646, IRV GO

character set and the ISO 646, IRV CO set.

3. The minimum level of support for Graphic String is the ISO

646, IRV GO character set and the 8859-1 GO and Gl sets,

4. This is the default when the parameter is not specified.

5. The implementation need not support Data Units whose total

character count exceeds 134.

6. As per table 9.3.

7. The length refers to the number of characters from the

applicable character set. It does not include any escape

sequences or overhead from the encoding.

8. If escape sequences are used in the encoding of the data

and string boundaries are not maintained when the file is

stored, it may be necessary for the escape sequences to

occur at different locations when the file is re-sent.

For document types which use the sequential flat constraint set,

conformant implementations must minimally support FADU identities as follows

o for Transfer service class: 'begin', 'end'

o for Transfer and Management service class: 'begin', 'end'

o for Access service class: 'begin', 'end', 'first', 'next'

9-10
June 1990 (Stable)

For the document types NBS-7 and NBS-8 used in conjunction with the

Transfer service class or the Transfer and Management service class, the

support of the FADU identities of 'current', 'next' and 'previous' and for

NBS-8 the support of the FADU identity of 'end' are outside the scope of

these Agreements.

9-10-1
!II I i

IS1
March 1990 (Stable)

For the document types NBS-6, NBS-7 and NBS-8 parameters are used for

which the Agreements apply as specified in table 9,2.

Table 9 .2. Parameters for NBS- 6, NBS-7, NBS-8

Parameter PrimType String- length Length1

Length2

int INTEGER Number of octets

required to represent,

in 2's complement

format, the largest

integer to be passed

bit BIT STRING Number of bits in

string

(non-varying)

ia5 lASString Max number of

characters in string

graphic Graphic

String

Max number of

characters in string

general General

String

Max number of

characters in string

octet OCTET STRING Max niambers of octets

in string

private

class-number

Floating

Point

Number

The minimum

number of bits

required to be

maintained in

the mantissa for

relative

precision

Number of

bits required

to represent

the largest

unbiased

integer ex- ponent in 2's

complement

univertime

UTCTime <not applicable>

gen- time Generalized

Time

<not applicable>

boolean BOOLEAN <not applicable>

null NULL <not applicable>

9-11
March 1990 (Stable)

Note: The string length parameter specifies the actual number of

from the referenced character set. It does not include any

escape sequences or overhead from the encoding.

The primitive data types and minimal size ranges that an implementation

must accept for storage are given in table 9.3.

Table 9.3. FTAM primitive data types

Primitive Data Tvtie Minimum Range (Octets)

ASN. 1 INTEGER 1 - 2

ASN. 1 BIT STRING 0 - 1 ASN. 1 lASString 0 - 134

ASN. 1 GeneralString 0 - 134

ASN. 1 GraphicString 0 - 134

ASN.l OCTET STRING 0 - 512

ASN. 1 BOOLEAN

ASN. 1 NULL

ASN. 1 General izedTime

ASN. 1 UniversalTime

NBS-ASl Float ingPointNumber mantissa 1-23 bits

exponent 0-8 bits

Notes: 1. The primitive data types and their maximum ranges for

a specific file as described by the parameters above

are maintained in the <contents type> file attribute.

The <contents type> file attribute value is

established at the file's creation and cannot be

changed via FTAM for the life of the file. This

implies that the data element types and ranges and

data unit formats are fixed for all accessors of that

file as long as the file exists.

2. The syntax for floating point numbers is part of the

definition of NBS abstract syntax ASl in Appendix C.3

Annex -9A -Part -3 . It is derived from existing standards

lEC 559 and IEEE 754.

9 . 10. 1 Character Sets

Implementation of a character set in FTAM is understood as:

o a transfer syntax is defined for the character set

o document types are defined using the character set in

their abstract syntactic definition

9-12
December '89

o documents of those types are stored in the Virtual File

Store as defined in the character set specification.

They are written into the VFS and read from the VFS as defined by the abstract syntax and the transfer syntax

for the document type. It is not in the scope of FTAM

Agreements to specify the local representation of those

documents in the Real Filestore, nor to specify

rendition of graphic characters or control characters

on character imaging devices. These renditions are possible agreements between applications using FTAM for

their communication.

The character sets ISO 646, IRV and ISO 8859-1 shall always be

implemented.

9. 10. 1 . 1 ISO 646 Character Set

The International Reference Version (IRV) of ISO 646 is

available for use when there is no requirement to use a national or an application-oriented version. In information

interchange, the IRV is assumed unless a particular

agreement exists between sender and receiver of the data.

The graphic characters allocated to the IRV are as specified

in table 9.4.

9-13
December '89

Table 9.4. IRV Graphic Character Allocations

Graphic Name Coded Representation

# Number sign 2/3

o Currency sign 2/4

(a Commercial at 4/0

[ Left square bracket 5/11

\ Reverse solidus 5/12

] Right square bracket 5/13

A Circumflex accent 5/14

f Grave accent 6/0

{ Left curly bracket 7/11

1 Vertical line 7/12

) Right curly bracket 7/13

Tilde, overline 7/14

It should be noted that no substitution is allowed when using the IRV

and that the facility of combined vertical and horizontal movements of

the active position does not apply to any format effectors.

It is permitted to use composite graphic characters and there is no limit to their number. Because of this freedom, their processing and

imaging may cause difficulties at the receiving end. Therefore

agreement between sender and receiver of the data is recommended if

composite characters are used.

Note: Attention is drawn to the fact that different national

character sets exist.

(See ISO 646 or CCITT Recommendation T.50 for more information)

9-14
December '89

9.10.1.2 Format Effectors

When a single format effector for vertical (or horizontal)

movement is optionally permitted to effect a combined

vertical and horizontal movement, implementations shall not

use the single format effector for effecting the combined

vertical and horizontal movement.

Notes: 1. For further information see ISO

646:1983, clauses 4.1.22 and 6.4, ISO

6429:1988, clause E.1.2 and ISO

4873:1986, clause A. 3. 2.

2. The Agreements require only support of

CO control characters of ISO 646,

containing among others the format

effectors <CR> and <LF>. It is

recommended that NIST implementations

use <CR> <LF> pairs as line

terminators

.

9. 10. 1 .3 8859-1 Character Set

The Latin Alphabet No.l (ISO 8859-1) is used to specify the

printable characters of GO and Gl . CO control characters

and their associated rules are taken from the ISO 646

definition.

9.10.2 Document Type Negotiation Rules

9.10.2.1 Connection Establishment

In connection establishment the <contents type list>

parameter is used only to establish presentation contexts.

Both the <document type name> form and the <abstract syntax

name> form are supported for responders; they are optionally supported for initiators.

9 10. 2 . 2 File Creation

An <F-CREATE request> FPDU must contain a <document type

name> value in its <initial attributes> parameter.

If the specified document type requires parameterization,

then these parameters must be supplied, otherwise the <FCREATE request> may be rejected.

9-15
December '89

Notes: 1. It is understood that <permitted actions>

sub-field of <lnitial attributes> parameter

will always be used at <F-CREATE request>.

The value may be changed by the Responder.

2. If the <document type name> used requires DU

syntax parameters and one of the parameters

specifies ' FloatingPointNumber ' as a primitive data type, the request may be

rejected, in case the optional type

'FloatingPointNumber' is not supported by the

Responder

.

9. 10.2.3 File Opening

The <document type name> form (with appropriate parameters

as specified in 8871-2, Clause 12.3) shall always be used

when proposing a <contents type>; as an alternative the

' ContentsTypeUnknown' value may be used in the <F-OPEN

request>. An <F-OPEN response> shall use the <document type

name> option (with appropriate parameters) in the <contents

type> field.

This allows the receiving entity to use the <document type

name> attributed to the file instead of receiving a <constraint set name> and <abstract syntax name> pair, which

does not reflect the file information contained in the FTAM

and NBS document types

.

This document type name is either a value from the set of

base document type names as negotiated upon connection

establishment or a document type name, for which an appropriate presentation context was established.

Notes: 1. An <F-OPEN response> without a <document type

name> (but carrying the <constraint set name>

and <abstract syntax name> form) may cause

the Initiator to issue an <F-CLOSE request>.

2. If the <document type name> used requires DU

syntax parameters and one of the parameters

specifies 'FloatingPointNumber' as a primitive data type, the request may be

rejected, in case the optional type

'FloatingPointNumber' is not supported by the

Responder

.

9-16
December '89

9.10.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 (IS08571-FADU definition in ISO 8571-

2, Clause 7.5). A Data Element is referred to as a FileContents- Data-Element in the IS08571-FADU definition.

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 DE types found in the file.

Because document types pertain to local processing and storage,

the DU syntax makes assertions about the syntax and the size of

DUs (records) in storage. Parameters on the document types

provide this information about the syntax and size of the DUs.

9.11 F- CANCEL ACTION

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

o no more data is sent,

o checkpoint numbers are removed, and

o state of the file is implementation dependent.

Note: When mapping F-CANCEL on P-RESYNCHRONIZE (abandon) it is

required that P-SYNC-MINOR be used after F-READ/F-WRITE (see

ISO 8571-4 Clauses 13, 14).

9-17
December '89

9.12 IMPLEMENTATION INFORMATION AGREEMENTS

o The <implementation information> parameter of <F-INITIALIZE>

FPDU is not required by these Agreements.

o It may be used to pass user version information as a series of

values , separated by '

; '

.

o The following will indicate conformance to the NIST Phase 2 Agreements : NBS - Phase2

.

Note: The list of possible values may be enlarged for future

FTAM phases or FTAM profiles of other bodies.

o This parameter is for information only; it is not used for

negotiation

.

The establishment of an FTAM regime should not be rejected only

because of an unknown <implementation information> value.

9. 13 DIAGNOSTIC AGREEMENTS

o The <diagnostic> parameter is supported; a value in the

<response> PDU is needed when the <action result> or <state

result> is not zero. (The nature of these agreements is to

provide <diagnostic> information when any result parameter is not

' success '

.

)

o General catch-all diagnostic action is discouraged.

o The <further details> subfield is supported. It will be encoded

as Graphics tring, but is restricted to ISO 646 (IRV, graphic

characters) and ISO 8859-1 only.

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

situations is discouraged.

o When returning an error status in a file management related

diagnostic (i.e.,, <F- READ -ATTRIBUTE response> or <FCHANGE-ATTRIBUTE response>) , identify the erroneous attribute by

using the first two characters of <further details> to hold a 2-digit number (encoded as lASString) from the <F-READ-ATTRIBUTE

request> attributes abstract syntax definition (ISO 8571-4,

Clause 20.3)

.

9-18
December '89

00 Filename

01 Permitted Actions

02 Contents Type

03 Storage Account

04 Date and Time of Creation

05 Date and Time of Last Modification

06 Date and Time of Last Read Access

07 Date and Time of Last Attribute Modification

08 Identity of Creator

09 Identity of Last Modifier

10 Identity of Last Reader

11 Identity of Last Attribute Modifier

12 File Availability

13 File Size

14 Future Filesize

15 Access Control

16 Legal Qualifications

17 Private Use

The set of file management diagnostics, found in ISO 8571-3 Annex

A, must be supported.

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

accommodated then the request fails and a <diagnostic> indicating

one such parameter should be returned by the responder. In the case where a negotiable parameter cannot be accommodated with

exactly the value requested but is negotiated to a different

value (as defined in the standard) then the request formally

succeeds but informative <diagnostics> indicating those

parameters negotiated should be returned.

In order to provide for robust applications using FTAM, well

defined and precise diagnostics are required to be returned by

responding implementations whenever an action cannot be carried

out precisely as requested with respect to non-negotiable

parameters. All such applicable diagnostics will be returned in

those cases. An action is carried out precisely as requested

with respect to a parameter when the value of that parameter on

the <request> FPDU is equal to the value in effect during or subsequent to the action, depending on whether the action is

regime control.

Diagnostics exist to signal 'parameter not supported' and

Responder implementations shall issue all appropriate

diagnostics. The <further details> subfield of the <diagnostic>

parameter shall specify the parameter which is not implemented.

9-19
December '89

9.14 CONCURRENCY

The <concurrency control> used by default on actions requested by an <F-SELECT indication> or <F-CREATE indication> service are:

'shared' for read and read attribute

'exclusive' for all other actions

The default for actions not requested is specified as 'not required'

as per ISO 8571-3.

Note: A local implementation may choose to be more restrictive in

order to assure file consistency for concurrent accessors.

FADU locking is not required.

9.15 REQUESTED ACCESS

The <requested access> parameter on <F-SELECT> or <F-CREATE> is used

to specify the actions which the Initiator may perform during the file

selection. The value of the <requested access> parameter is compared

by the Responder to the <access control> and <permitted actions> file

attributes and concurrency controls (including those requested by the

Initiator) currently in place on the file. If the value of the

<requested access> parameter is not consistent with either <access

control>, <permitted actions>, or concurrency controls in place, then

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

<requested access> is consistent with <access control> if, for each

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

required password has been specified on the <F- SELECT request> or <FCREATE request>.

<requested access> is consistent with <permitted actions> if, for each

action requested, that action is allowed by the <permitted actions>

file attribute.

<requested access> is consistent with <concurrency control> requested

on the <F-SELECT> or <F-CREATE> if, for each action requested, that

action has not been specified as 'not required' or 'no access' in the

<concurrency control> parameter.

<requested access> is consistent with concurrency controls in place on

the file if for each action requested no other accessor of the file

has set the concurrency control for that action to either 'exclusive'

or ' no access '

.

9-20
December ' 89

9. 16 SECURITY

9.16.1 Initiator Identity and Filestore Password

The <initiator identity> and <filestore password> parameters for an implementation acting as an Initiator are supported. These

parameters are optional for an implementation acting as a Responder.

The syntax of <initiator identity> and <filestore password> is

system-dependent. <initiator identity> and <filestore password>

will represent account information on the local system, which

may be different from the <account> parameter.

9.16.2 Access Passwords

The <access passwords> and <create password> parameters for an implementation acting as an Initiator are supported if the

Security Group of attributes is supported. These parameters for an implementation acting as a Responder are optionally supported

if the Security Group is supported.

9.16.3 Implementation Responsibilities

It is the responsibility of each local system to provide security

for its own real filestore. Encryption of passwords will not be

done by FTAM.

A user of the file service must be known by the Responder.

"Known" is defined by the local Filestore, and is dependent on

the level of security provided by the local Filestore.

9.17 REQUIREMENT FOR CONFORMANT IMPLEMENTATIONS

This section gives the criteria to be satisfied by every

implementation of FTAM that conforms to these Agreements.

Conformance to these Agreements is stated in terms of the different

roles occupied by FTAM implementations. The interoperability of

certain configurations of these roles motivates this approach.

Interoperable configurations of these roles are given in section

9.17.1.

The only function provided by every conformant implementation is the

transfer of unstructured binary files in their entirety. It must be

recognized that such simple transfer, while commonly understood and

generally important, will not support all applications of FTAM.

section 9.18 defines Implementation Profiles of FTAM services and

protocol that can provide other specific functions. Those other

9-21
December '89

functions exploit the access and management capabilities of FTAM. The

unconstrained service class (with appropriately chosen functional

units) can be used to provide the functions of any of the

Implementation Profiles. Users of FTAM must consider carefully what

functions they require. They must examine all the Implementation

Profiles and select according to their needs.

Implementation conforming to these Agreements require adherence to

the General Agreements in sees. 9.5 through 9.16 of these Agreements.

9.17.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,

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 sees. 9.17.3 to 9.17.8).

Any implementations of roles 2 and 4 will be able to interoperate

at the intersection of their capabilities (which will be at least

the minimal capabilities described in sects. 9.17.3 to 9.17.8).

These role combinations and this interoperability are shown in

table 9.5 below.

9-22
December ' 89

Table 9.5. Interoperable configurations

Initiator Responder

sender receiver sender receiver

Initiator

sender X

receiver X

Responder

sender X

receiver X

9.17.2 Relationship to ISO 8571 --The FTAM Standard

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

8571-4, Clause 22 (Conformance)), in addition to the

implementation of the minimal protocols and roles enumerated in

sections 9.17.3 to 9.17.8, is considered to be in conformance

with these Agreements. Any implementation violating any of the

conformance statements in ISO 8571-4 is considered to be in

violation of these Agreements.

9.17.3 Requirements for Document Type Support

The document type FTAM- 3 shall be supported for purposes of

transfer and storage. The details regarding support for FTAM3

in the FTAM dialogue are given in section 9.10.

Support of document types other than FTAM- 3 is not required for

conformant implementations. Support for document types described

in these Agreements also entails support for:

o the semantics given in their description and further

qualified in 9.10

o the preferred transfer syntax "Basic Encoding of a single ASN.l type"

9.17.4 Initiators

Every implementation of an FTAM Initiator shall support:

o the kernel protocol and its mandatory parameters with

9-23
December '89

minimum ranges [Minimum required ranges are specified

in sec. 9.17.8. ] ,

o the grouping protocol and the <threshold> parameter

with a value of at least 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 sees. 9.17.6 and 9.17.7. ]

,

and support the applicable procedures defined in ISO 8571-4

clauses 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), 8.12 (End

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

protocols and procedures the implementation shall always support

the kernel functional unit and additionally shall be able to:

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

o request the file transfer class with the <service

class> parameter,

o request the document type FTAM-3 using the <document

type name> form of the <contents type> parameter,

o request the <FTAM quality of service> parameter with

value 0 and accept in all cases the returned value 0,

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 clause 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 <F- INITIALIZE response> FDU. Initiators must be

able to operate with any downward negotiation of requested

parameter values as described in the standard.

Should the supporting services break down, such that FTAM

communication is impossible, the FTAM protocol machine shall

notify the user with an <F-P-ABORT indication> and <diagnostic>

value with identifier 1011, as well as any known <further

details>

.

Note: Interworking may not be possible between Initiators not

supporting attributes of the Storage Group and Security

9-24
December '89

Group, and Responders requiring these attributes to be

used.

9.17.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 sec. 9.17.8. ] ,

o the grouping protocol and the <threshold> parameter

with a value of at least 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 9.17.6 and 9.17.7],

and support the applicable procedures, defined in ISO 8571-4

clauses 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), 9.12 (End

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

protocols and procedures the implementation shall always support

the kernel functional unit and additionally shall be able to:

o accept requests for the grouping and at least one of

the read or write functional units,

o accept requests for the file transfer class with the

<service class> parameter,

o accept the document type FTAM- 3 using the <document

type name> form of the <contents type> parameter,

o accept requests for an <FTAM quality of service>

parameter with any value but may respond with the

value 0 , 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-

4 clause 9.1, FTAM regime establishment.

Responders must be able to operate under all circumstances if

the above minimum values are requested on an <F- INITIALIZE

request> PDU. Responders must not negotiate upward in the sense described in the standard.

9-25
December '89

Responders must complete each action requested and supported in a manner consistent with its description in ISO 8571-2 Clauses 10

(Actions on complete files) and 11 (Actions for file access), and

must interpret each supported attribute in a manner consistent

with its definition in ISO 8571-2 Clause 12 (File attributes).

Under circumstances where actions cannot be carried out either as requested or consistently with ISO 8571-2 Clause 10 (Actions on complete files) and 12 (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 parameter, 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-P-ABORT indication> and <diagnostic>

with identifier 1011, as well as inform the user of any known

<further details>.

9.17.6 Senders

Every implementation of an FTAM sender shall support the read

functional unit as Responder or the write functional unit as Initiator, and support the applicable procedures defined in ISO

8571-4 Clauses 11 (State of the bulk data transfer activity), 12

(Bulk data transfer protocol data units) , 15 (Bulk data transfer

sending entity actions), 17.1 (Discarding), and 17.2 (Cancel).

To support those procedures the implementation shall be able to

send files of the document type FTAM- 3 and shall be able to send

them as user data in PPDUs in blocks of up to 7168 octets.

9.17.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 FTAM- 3 the following bulk

data transfer specification parameters:

9-26
December '89

FADU operation replace

FADU identity first

and support the applicable procedures, defined in ISO 8571-4

Clause 13 (Bulk data transfer initiating entity actions)

.

9.17.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 FTAM- 3 the following bulk

data transfer specification parameters:

FADU identity first

Access context UA

and support the applicable procedures, defined in ISO 8571-4

Clause 14 (Bulk data transfer responding entity actions)

.

9.17.7 Receivers

Every implementation of an FTAM receiver shall support the read

functional unit as Initiator or the write functional unit as Responder, and support the applicable procedures, defined in ISO

8571-4 Clauses 11 (State of the bulk data transfer activity), 12

(Bulk data transfer protocol data units), 16 (Bulk data transfer

receiving entity actions), 17.1 (Discarding), and 17.2 (Cancel).

To support those procedures the implementation shall be able to

receive files of the document type FTAM- 3 and shall be able to

receive them as user data in PPDUs in blocks of at least 7168

octets

.

9.17.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 FTAM- 3 the following bulk

data transfer specification parameters:

FADU identity first

Access context UA

9-27
December '89

and support the applicable procedures, defined in ISO 8571-4

Clause 13 (Bulk data transfer initiating entity actions)

.

9.17.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 FTAM- 3 the following bulk

data transfer specification parameters:

FADU operation replace

FADU identity first

and support the applicable procedures, defined in ISO 8571-4

Clause 14 (Bulk data transfer responding entity actions)

.

9.17.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 9.6. A conforming implementation may support a wider

range of values for any parameter.

9-28
December '89

Table 9.6. Required minimal parameter support

Parameter Minimuin Range

general

F INITIALIZE

diagnostic

action result

state result

functional units

presentation context managements^

all others

F SELECT

attributes

requested access

F- CREATE

override

Values as specified in ISO 8571-3 Annex A

(Diagnostic parameter values) tables 44,

45 and 46 which correspond directly to

mandatory parameters.

All values.

All values.

'read' (for initiator/receivers and

responder/senders) and 'grouping'

or

'write' (for initiator/senders and

responder/receivers) and 'grouping'

'False'

As specified in sections 9.17.4 and

9.17.5 above.

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 Clause 15

(Minimum attribute ranges) table 2.

'read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

For Responders , the values 'createfailure', ' select-old- file ' and

' delete-and-create-with-new-attributes

are supported. The value ' delete -andrecreate-with-old-attributes ' is

optionally supported. All values are optional for Initiators.

(Continued on next page.)

9-29
December '89

Table 9.6. Required minimal parameter support, continued

Parameter Minimum Range

F_ OPEN

processing mode ' read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

contents type FTAMi

F READ

FADU identity ' first' access context 'UA'

F_ WRITE

FADU operation 'read' for initiator/receivers

'read' for responder/senders

'replace' for initiator/senders

'replace' for responder/receivers

FADU identity 'first'

F__BEGIN_GROUP

threshold-^ For file transfer (a minimal required

function) 2.

For any other supported parameters , minimum ranges are taken from

the minimum ranges for the attribute corresponding to each as in

ISO 8571-2 table 4.

Notes: 1. The parameters, functional units, and presentation context

management are not ordered, so "minimum value" cannot be

formally defined. The above values are those required for

conformance to these Agreements but no value conformant to

ISO 8571 for use in other applications is regarded to be in

violation of these Agreements.

2. Other functional units (and service classes) for defined

implementations may also be valid provided that they are implemented in accordance with these Agreements,

specifically section 9.17.8.

3. Every implementation must support the <threshold> value 2 to

provide the basic required function of file transfer; any

other value in other applications is acceptable.

9. 17 .9 Range of Values for INTEGER Type Parameters

9' 30
March 1990 (Stable)

The general range for parameters of type INTEGER to the FTAM PCI

is as specified in the UNIVERSAL ASN.l ENCODING RULES section of

the Upper Layers chapter.

The parameters

FTAM Attributes

filesize

future - files ize

FADU- Identity

fadu- number

may be encoded so that the length of its contents octets is no more than eight octets.

In the case of receiving more than 4 contents octets , the

receiver may reject the corresponding FTAM PDU.

Note: To guarantee interworking , encoding should be

restricted to the range -2^-'^ to 2-^-^-1.

Use of Lower Layer Services

Support for the Presentation Context Management

functional unit is not required.

Implementations will support the Session,

Presentation, and ACSE requirements as stated in

section 5 of this document.

Implementation of the Session Resychronize and the

Minor Synchronize functional units is highly

recommended, since the F-CANCEL service may be less

effective when mapped to S-DATA.

9. 18 IMPLEMENTATION PROFILES

This section defines Implementation Profiles for the specific

functions of:

o File Transfer

o File Access

o File Management.

Those definitions are expressed in terms of:

o Document Types

o Attributes

9.17.10

Note:

9-31
March 1990 (Stable)

o Service Classes (both service elements and their

parameters)

.

This by no means defines all possible Implementation Profiles.

The following Implementation Profiles are defined:

Tl: Simple File Transfer

9-31-1

March 1990 (Stable)

T2

T3

Al

A2

Ml

Positional File Transfer

Full File Transfer

Simple File Access

Full File Access

Management

.

Implementation Agreements have been reached for the following service

classes. Note that any given implementation may support more than one service class.

o File Transfer

o File Access

o File Management

o Unconstrained

o File Transfer and Management

Support of an Implementation Profile requires adherence to:

1. corresponding definition in 8571-3 Clause 8 and any related

procedures in 8571-4 Clause 8-17,

2. requirements given in sections 9.5-9.18 of these Agreements, and

3. requirements for parameter and attribute support as defined in

section 9.17.8.

9.18.1 General Requirements for the Defined Implementation

Profiles

o Implementations will be able to act either as Initiator or Responder or both.

o Implementations must support diagnostics as described in

section 9.13 of these Agreements.

o Implementations that support the file access service class

will support access to sequential files. Support of

sequential files entails hierarchy of depth and arc length

equal to 1 . Other hierarchy depth and arc lengths are not

precluded by these agreements.

9.18.2 (deleted)

9.18.3 Document Type Requirements for the Defined

Implementation Profiles

Implementations conformant to Implementation Profiles defined in

table 9.7 will support the following document types with the

caveats and procedures given. Those document types are defined

9-32
December '89

in Appendix 9A and section 9.10 of these Agreements, and in ISO

8571-2.

o FTAM1

o FTAM2

o FTAM3

o NBS-6

o NBS-7

Note: Support of this document type entails the

naming of FADUs by their position in

preorder traversal.

Caveat: Other methods of naming FADUs depend on the

system, application, and specific file, and

as such are not described here

.

o NBS-8

o NBS-9

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 syntaxes for the parameterized

document types NBS-6, 7, 8 are not specified in these

Agreements

.

Any document type supported must be identifiable by its document

type name as given in ISO 8571-2 and in Appendix 9A of these

Agreements and, where defined, the parameterization scheme given

in section 9.10 of these Agreements.

For conformance to NBS-9 a Responder is only required to return

the <filename> attribute, subject to local security and access

control. All other requested attributes need not be returned.

Systems supporting the NBS-9 document type shall make available

an NBS-9 document called 'DIRLIS'. This document can be used to

obtain a listing of files and their associated attributes from a remote Filestore.

Creation and deletion of NBS-9 files are outside the scope of

these Agreements

.

File security issues related to NBS-9 are subject to the security

agreements outlined in section 9.16.

9-33
December '89

9.18.4 Parameters for the Defined Implementation Profiles

o Implementations will support the <contents type list>

parameter on the <F-INITIALIZE> service element. The

initiating service must supply a value for this

parameter

.

o Implementations will support the <diagnostic> parameter

as stated in section 9.13 of these Agreements.

o The <initiator identity> parameter is supported. Use

must be consistent with section 9.16 of these

Agreements

.

o Implementations are not precluded from using other

parameters for security and/or accounting.

Respondersmust state the syntax and the semantics

applying to <account> and <charging> parameters. The

Responder's minimum implementation is to accept but

ignore the <account>.

9.18.5 Parameter Ranges for the Defined Implementation

Profiles

Parameter ranges for Implementations Profiles are as stated for

primitive data types in section 9.10 of these agreements.

9.18.6 File Attribute Support for Implementations

Implementations of the Implementation Profiles will support file

attributes or attribute groups in the following ways.

o mandatory

This feature is mandatory in the ISO 8571-2

standard and shall therefore be implemented by all

implementations claiming conformance to these

Agreements

.

o supported

This feature shall be implemented by all

implementations claiming conformance to these

Agreements (for attributes, this implies that at

least the minimum range of attribute values, as defined in ISO 8571-2 Clause 15, shall be

supported) . Conformant implementations shall also

be able to interwork with other implementations

that do not support this feature by negotiating

out the corresponding features.

o optionally supported

9-34
December ' 89

Implementations claiming conformance to these

Agreements may or may not implement this feature

(for attributes, this implies that at least either

the minimum range of attribute values, as defined

in ISO 8571-2 Clause 15, shall be supported or that the 'no value available' result shall be

supplied) . If an attribute group with a support

level of 'optionally supported' is chosen to be

supported, then all the attributes of this group

that are classified as 'mandatory' or 'supported'

shall be supported.

o not supported

This feature is outside the scope of these

Agreements

.

Kernel Group mandatory

o Filename

o Permitted Actions

o Contents Type

Storage Group

o Storage Account

o Date and Time of Creation

o Date and Time of Last Modification

o Date and Time of Last Read Access

o Date and Time of Last Attribute Modification

o Identity of Creator

o Identity of Last Modifier

o Identity of Last Reader

o Identity of Last Attribute Modifier

o File Availability

o Filesize

o Future Filesize

Security Group

o Access Control

o Legal Qualifications

mandatory

mandatory

mandatory

optionally supported

optionally

optionally

optionally

optionally

optionally

optionally

optionally

optionally

optionally

supported

supported

optionally

supported

supported

supported

supported

supported

supported

supported

supported

supported

supported

optionally supported

supported

optionally supported

Private Group not supported

9-35
December '89

Table 9.7. Implementation profile support requirements

Functional Unit T

Service Class (See Note 8)

M A T&M UNCST

Kernel

Read (See note 3.)

Tl ,T2,T3

T1,T2,T3

Ml Al,A2

A1,A2

Write (See note 3.) Tl ,T2,T3 Al ,A2

Limited File Mgmnt

.

Enhanced File Mgmnt.

Grouping

File Access

SeeNote 6

T1,T2,T3

Ml

Ml

Ml

SeeNote 6

Al ,A2

See See

Document Types

FTAM-1

FTAM-2

FTAM-3

Tl ,T2,T3

T2,T3

Tl ,T2,T3

[Ml]

[Ml]

[Ml]

Al ,A2

Al ,A2

Al ,A2 Note Note

NBS-6 [T2] ,T3 [Ml] [Al] ,A2 4 5

NBS-7 [T2] ,T3 [Ml] [Al] ,A2

NBS-8 T3 [Ml] A2

NBS-9 [Tl] , [T2]

[T3]

[Ml]

Notes: to 9.18.3 and table 9.7

1. The Management Implementation Profile is only to be implemented in

conjunction with one of the Transfer or Access Profiles.

2. Profile T2 is subset of T3 . Al and Tl are subsets of A2 and T2,

respectively.

3. Profiles Tl , T2, and T3 require the support of read and/or write

functional units

.

4. Support of the <File Transfer and Management> service class is

optional. The rules for including it in a request and for the

response to it are as given in ISO 8571-3, Clause 10.1. Any

implementation including TM in the request must be prepared for the

possibility that it might be removed from the response.

9-36
December '89

5. The support of the <Unconstrained> service class is outside the scope

of these Implementation Profiles.

6. Limited File Management is not required for the T- and AImplementation Profiles, but very often it will be a user request to

have limited file management functionality available together with

file transfer and file access functions. So Limited File Management

may be added as an option to the T- and A- Implementation Profiles.

7. [] in table 9.7 specifies that the document type is optional for the

respective Implementation Profile. For Ml the support level depends

on the T- or A- Implementation Profile, in conjunction with which Ml

is implemented.

8. The Implementation Profiles specify functionality which includes the

requirements for conformant implementations as specified in section

9.17. This is a general basic requirement and is not also reflected

in table 9.7.

9 19 PROVISION OF SPECIFIC FUNCTION

9.19.1 Implementation Profile Tl : Simple File Transfer

Implementation Profile Tl provides the function of transferring

entire files at the external file service level for files v/ith an unstructured constraint set. This includes support of the

document types

o FTAM-1 "ISO FTAM unstructured text"

o FTAM-3 "ISO FTAi4 unstructured binary"

o NBS-9 "NBS-9 file directory file" (optional)

This Implementation Profile supports file transfer and not file

access, that is, the ability to:

o read a complete file

and/or

o write (replace, extend) to a file.

9 . 19 .2 Implementation Profile T2 : Positional File Transfer

Implementation Profile T2 provides the function of transferring

files at the external file service level for files with an unstructured or fiat constraint set. This includes support of

the document types

o FTAM-1 "ISO FTAM unstructured text"

o FTAM- 2 "ISO FTAM sequential text"

9-37
December '89

o FTAM-3 "ISO FTAM unstructured binary"

o NBS-6 "NBS-6 FTAM sequential file" (optional)

o NBS-7 "NBS-7 FTAM random access file" (optional)

o NBS-9 "NBS-9 file directory file" (optional)

This Implementation Profile supports file transfer and not file

access, that is, the ability to:

o read a complete file or a single FADU which is

identified by position

and/or

o write (replace, extend, insert depending on constraint

set and document type) to a file or an FADU.

This Implementation Profile is upwardly compatible to Tl for the

transfer of unstructured files.

9.19.3 Implementation Profile T3 : Full File Transfer

Implementation Profile T3 provides the function of transferring

files at the external file service level for files with an unstructured, flat or general hierarchical constraint set. This

includes support of the document types:

o FTAM-1 "ISO FTAM unstructured text"

o FTAM2"ISO FTAM sequential text"

o FTAM-3 "ISO FTAM unstructured binary"

0 NBS-6 "NBS- 6 FTAM sequential file"

o NBS-7 "NBS- 7 FTAM random access file

o NBS-8 "NBS- 8 FTAM indexed file"

o NBS-9 "NBS- 9 file directory file"

This Implementation Profile supports file transfer and not file

access, that is, the ability to:

o read a complete file or a single FADU which is

identified by key or by position

and/or

o write (replace, extend, insert depending on constraint

set and document type) to a file or an FADU.

This Implementation Profile is upwardly compatible to Tl for the

transfer of unstructured files.

9.19.4 Implementation Profile Al : Simple File Access

9-38
December '89

Implementation Profile Al provides the function of transfer of

and access to files with unstructured or flat constraint sets at

the external file service level. This includes support of the

document types:

o FTAM-1 "ISO FTAM unstructured text"

o FTAM- 2 "ISO FTAM sequential text"

o FTAM- 3 "ISO FTAM unstructured binary"

o NBS-6 "NBS-6 FTAM sequential file" (optional)

o NBS-7 "NBS-7 FTAM random access file" (optional)

This Implementation Profile supports file transfer and file

access, that is the ability to:

o read a complete file or FADUs which are identified by

position,

o write (replace, extend, insert depending on constraint

set and document type) to a file or an FADU,

o locate and erase within files.

9.19.5 Implementation Profile A2 : Full File Access

Implementation Profile A2 provides the function of transfer of

and access to files with unstructured or flat constraint sets at

the external file service level. This includes support of the

document types:

o FTAM-1 "ISO FTAM unstructured text"

o FTAM2

"ISO FTAM sequential text"

0 FTAM3

"ISO FTAM unstructured binary"

o NBS-6 "NBS- 6 FTAM sequential file"

o NBS-7 "NBS- 7 FTAM random access file

o NBS-8 "NBS- 8 FTAM indexed file"

This Implementation Profile supports file transfer and file

access, that is, the ability to:

o read from a complete file, or from a series of FADUs

which are identified by key or by position,

o write (replace, extend, insert depending on constraint

set and document type) to a file or an FADU,

o locate and erase within files.

9-39
December '89

9.19.6 Implementation Profile Ml: Management

Implementation Profile Ml provides the function for an Initiator

to manage the files within the Virtual Filestore, to which access

is provided by the Responder. Management includes the services

of:

o creating a file

o deleting a file

o reading attributes of a file

o changing attributes of a file.

9 . 20 HARMONIZATION

The Implementation Profiles for File Transfer, File Access and

Management correspond to the Profiles of SPAG (Standards Promotion

and Application Group) in Europe, so that interworking will be

possible. Those Profiles are described in the 'Guide to the Use of

Standards' (GUS) ; they are the basis for the Functional Standards as defined by CEN/CENELEC (Comite Europeenne de Normalization)

.

Table 9.8. Implementation Profiles (NIST) and Profiles (SPAG/CEN-CLC)

Implementation Profile SPAG/CEN-CLC

Tl A/111

T2 A/112

T3 A/113

Al A/122

A2 A/123

Ml A/13

9-40
June 1990 (Stable)

APPENDICES

APPENDIX A: FTAM DOCUMENT TYPES

APPENDIX B: CONSTRAINT SETS

APPENDIX C: ABSTRACT SYNTAXES

9-41
June 1990 (Stable)

APPENDIX A: FTAM DOCUMENT TYPES

A.

1

NBS-6 Sequential file document type

This object with Object Identifier

{ iso identified-organization icd(9999) organization-code (1) dociomenttype ( 5 ) sequential ( 6 )

)

was withdrawn on March 16, 1990. It was replaced with the object NBS-6

Sequential file document type with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document- type (5)

sequential (6)

)

defined in chapter 9, A. 5.

A. 2 NBS-7 Random access file

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(l) documenttype(5) random-file (7)

}

was withdrawn on March 16, 1990. It was replaced with the object NBS-7

Random access file document type with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document- type (5)

random-access (7)

)

defined in chapter 9, A. 6.

A.

3

NBS-8 Indexed sequential file

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(l) documenttype(5) indexed-file(8)

)

was withdrawn on March 16, 1990. It was replaced with the object NBS-8

Indexed sequential file document type with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document- type (5)

indexed-file(8)

)

defined in chapter 9, A. 7.

A. 4 NBS-9 File directory file

This object with Object Identifier

{iso identified-organization icd(9999) organization-code(l) documenttype(5) file directory(9)

)

was withdrawn on March 16, 1990. It was replaced with the object NBS-9

File directory file document type with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) document -type (5) filedirectory (9) ) defined in chapter 9, A. 8.

9-42
Part -1 ^ - -Doeament -Types

A.

5

NBS-6 Sequential file document type

1. Entry Number: NBS-6

2. Information objects

March 1990 (Stable)

9-42-1

March 1990 (Stable)

Table 9.9. Information objects in NBS-6

1 document type name

1 {iso identified-organization oiw(14)

ftamsig(5) ted(-9999V -organization-eode(-l)

document -type (5) sequential (6)

}

"NBS-6 FTAM sequential file"

abstract syntax names: {iso identified-organization oiw(14)

a) name for asnamel ftamsig(5) ted(-999)- -organizatton-eode(^l)

abstract-syntax(2) nbs-asl(l)}

"NBS abstract syntax ASl"

b) name for asname2 {iso standard 8571 abstract-syntax(2) ftamfadu(2)

)

"FTAM FADU"

transfer syntax names: { j oint- iso-ccitt asnl(l) basic-encoding(l)

} "Basic Encoding of a single ASN.l type"

parameter syntax:

PARAMETERS : := SEQUENCE OF CHOICE {ParameterO, Parameterl , Parameter2}

ParameterO : := [0] INTEGER {univer-time (23),

gen- time (24)

,

boolean (1)

,

null (5) } Parameterl : := [1] SEQUENCE { universal-class-number-1 INTEGER { int (2),

bit (3),

ia5 (22),

graphic (25)

,

general (27)

octet (4) }

,

string- length INTEGER } Parameter2 : := [2] SEQUENCE { private-class-number INTEGER {float (0)),

length- 1 INTEGER,

length- 2 INTEGER }

file model {iso standard 8571 file-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4)

sequential-flat (2)

)

"FTAM sequential flat constraint set"

file contents:

Datatypel : := PrimType -- as defined in Appendix C.3

Annex -9A ,- -Part -3 Datatype2 : := Node -Descriptor -Data -Element

9-43
March 1990 (Stable)

3. Scope and field of application

The document type defines the contents of a file for storage, for

transfer and access by FTAM.

Note: Storage refers to apparent storage within the Virtual

Filestore.

4. References

ISO 8571, Information Processing Systems - Open Systems

Interconnection - File Transfer, Access and Management

5 . Definitions

, This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6. Abbreviations

FTAM File Transfer, Access and Management

7 . Document semantics

The document consists of zero, one or more file access data units,

each of which consists of zero, one or more data elements. The order

of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the sequential flat

constraint set (see table 9.9) These definitions appear in ISO 8571-

2. As additional constraints FADU identity will be limited to

'begin', 'end', 'first' and 'next'.

For a specific file the number of data elements in a data unit is

given by the parameters. Each data element is a data type from the

I set of primitive data types defined in the Appendix C.3 Annex -9A ,- -Part

I 3 of this document. Each data unit contains the same data element

types in the same order as all other data units. These types are determined by the parameters 0 through 2.

The string length field of Parameterl specifies the length of the

value in octets for the INTEGER, BIT STRING and OCTET STRING types.

For character- type data elements, the string- length indicates the

actual number of characters from the specified character set, not

including any escape sequences or overhead from the character

encoding.

For floating point numbers, finite form, length- 1 and length2

specify the length in bits of mantissa and exponent, respectively.

The length- 1 and length-2 values are irrelevant for the other choices

of floating point numbers.

9-44
December '89

8. Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically

structured file as defined in the ASN.l module IS08571 -FADU in ISO

8571, in which each of the file access data units has the abstract

syntactic structure of NBS-ASl as defined by the parameters.

9, Definition of transfer

9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 9.9, where the PrimType in

the datatype is given by the NBS-ASl definition; or

b) Datatype2 defined in table 9.9, the ASN.l datatype

declared as "Data-Element" in the ASN.l module IS08571-

FADU.

9 . 2 Presentation data values

The document is transferred as a series of presentation data

values, each of which is either

a) one value of the ASN.l datatype "Datatypel," carrying

one of the data elements from the document. All values

are transmitted in the same (but any ) presentation

context defined to support the abstract syntax name

"asnamel" or

b) a value of "Datatype2." All values are transmitted in

the same (but any) presentation context defined to

support the abstract syntax name "asname2."

Notes

1. Specific carrier standards may impose additional constraints

on the presentation context to be used, where the above

permits a choice

2. Any document type defined in this entry either makes no use

of Datatype2 , or starts with a Datatype2 transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between P-DATA primitives,

are chosen locally by the sending entity at the time of

transmission, and carry no semantics of the document type.

Receivers which support this document type shall accept a document with any of the permitted transfer options (e.g.,

document type parameters and transfer syntaxes).

9-45
December '89

9 . 3 Sequence of presentation data values

The sequence of presentation data values of type a) and the

sequence of presentation data values of types a) and b) is the same as the sequence of data elements within a Data Unit, and

Data Units in the hierarchical structure, when flattened

according to the definition of the hierarchical file model in ISO

8571-2.

10. Transfer syntax

An implementation supporting this document type shall support the

transfer syntax generation rules named in table 9.9 for all

presentation data values transferred. An implementation may

optionally support other named transfer syntaxes.

11. ASE specific specifications for FTAM

11.1 Simplification and relaxation

11.1.1 Structural simplification

This simplification loses information.

The document type NBS-6 may be simplified to the document type

FTAM-3 (allowed only when reading the file) . The octet

representation of the transferred data is unpredictable. It will

usually correspond to the data values as stored in the local Real

Filestore of the Responder,

11.2 Access context selection

A document of type NBS-6 may be accessed in any one of the access contexts defined in the sequential flat constraint set. The

presentation data units transferred in each case are those

derived from the structuring elements defined for that access context in ISO 8571-2.

11.3 The INSERT operation

When the <INSERT> operation is applied at the end of file the

transferred material shall be the series of FADUs which would be

generated by reading any NBS-6 document with the same parameter

values in access context FA.

9-46
A.

6

NBS-7 Random access file

1. Entry nijmber: NBS-7

2. Information objects

March 1990 (Stable)

9-47
March 1990 (Stable)

Table 9.10. Information objects in NBS-7

document type name {iso identified-organization oiw(14)

ftamsig(5) ted(^9999> - -organtzati:on-eode(-lr)

document - type ( 5 ) random- f i le ( 7 )

)

"NBS-7 FTAM random access file"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14)

ftamsig(5) ied(^9999> -organtzation-eodeft)

abstract- S3mtax( 2) nbs-asl(l)}

"NBS abstract syntax ASl"

{iso standard 8571 abstract-syntax(2) ftamfadu(2)) "FTAM FADU"

transfer syntax names: { joint-iso-ccitt asnl(l) basic-encoding(l)

} "Basic Encoding of a single ASN.l type"

parameter syntax:

PARAMETERS : := SEQUENCE OF CHOICE {ParameterO, Parameterl, Parameter2}

ParameterO : := [0] INTEGER {univer-time (23),

gen- time (24)

,

boolean (1)

,

null (5) ) Parameterl : := [1] SEQUENCE { universal-class-number- 1 INTEGER { int (2),

bit (3),

ia5 (22),

graphic (25),

general (27)

,

octet (4) )

,

string- length INTEGER } Parameter2 : := [2] SEQUENCE { private-class-number INTEGER {float (0)},

length- 1 INTEGER,

length- 2 INTEGER }

file model {iso standard 8571 f ile-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso identified-organization oiw(14)

ftamsig(5) iedf9999)- -organization -eodeft)

constraint-set (4) nbs ordered-flat(l)

)

"NBS ordered flat constraint set"

file contents:

Datatypel : :=

Datatype2 : : =

PrimType -- as defined in Appendix C.3

Annex -9A ,- -Part -3

CHOICE { Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element ) Exit-Subtree-Data-Element )

q-4«
March 1990 (Stable)

3. Scope and field of application

The document type defines the contents of a file for storage, for

transfer and access by FTAM.

Note: Storage refers to apparent storage within the Virtual

Filestore

.

4 . References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management

5 . Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6 . Abbreviations

FTAM File Transfer, Access and Management

7 . Document semantics

The document consists of zero, one or more file access data units,

each of which consists of zero, one or more data elements. The order

of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the NBS -ordered- flat

constraint set (see table 9.10). These definitions appear in

Appendix B.2 9A,--Part-2 of this document.

For a specific file the number of data elements in a data unit is

given by the parameters. Each data element is a data type from the

set of primitive data types defined in the Appendix C.3 Annex -9A ,- -Part

S of this document. Each data unit contains the same data element

types in the same order as all other data units. These types are determined by the parameters 0 through 2.

The string length field of Parameterl specifies the length of the

value in octets for the INTEGER, BIT STRING and OCTET STRING types.

For character- type data elements, the string- length indicates the

actual number of characters from the specified character set, not

including any escape sequences or overhead from the character

encoding.

For floating point numbers, finite form, length- 1 and length2

specify the length in bits of mantissa and exponent, respectively.

The length- 1 and length-2 values are irrelevant for the other choices

of floating point numbers.

9-49
March 1990 (Stable)

8. Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically

structured file as defined in the ASN.l module IS08571-FADU in ISO

8571, in which each of the file access data units has the abstract

syntactic structure of NBS-ASl as defined by the parameters.

9. Definition of transfer

9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 9.10, where the PrimType in

the datatype is given by the NBS-ASl definition; or

b) Datatype2 defined in table 9.10, the ASN.l datatype

declared as "Data-Element" in the ASN.l module

IS08571-FADU.

9 . 2 Presentation data values

The document is transferred as a series of presentation data

values, each of which is either

a) one value of the ASN.l datat3rpe "Datatypel," carrying

one of the data elements from the document. All

values are transmitted in the same (but any ) presentation context defined to support the abstract

syntax name "asnamel" or

b) a value of " Datatype2 . " All values are transmitted

in the same (but any) presentation context defined to

support the abstract syntax name " asname2."

Notes: 1. Specific carrier standards may impose additional

constraints on the presentation context to be

used, wheie the above permits a choice

2. Any document type defined in this entry either

makes no use of Datatype2 , or starts with a Datatype2 transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between P-DATA primitives,

are chosen locally by the sending entity at the time of

transmission, and carry no semantics of the document type.

Receivers which support this document type shall accept a document with any of the permitted transfer options (e.g.,

document type parameters and transfer syntaxes).

9-50
December ' 89

9 . 3 Sequence of presentation data values

The sequence of presentation data values of type a) and the

sequence of presentation data values of types a) and b) is the same as the sequence of data elements within a Data Unit, and

Data Units in the hierarchical structure, when flattened

according to the definition of the hierarchical file model in ISO

8571-2.

10. Transfer syntax

An implementation supporting this document type shall support the

transfer syntax generation rules named in table 9.10 for all

presentation data values transferred. Implementation may

optionally support other named transfer syntaxes.

11. ASE specific specifications for FTAM

11.1 Simplification and relaxation

11.1.1 Structural simplification

This simplification loses information.

The document type NBS-7 may be accessed as a document type FTAM3

(allowed only when reading the file) by specifying document type

FTAM-3 in the <contents type> parameter in <F-OPEN request>, and

limiting access context to UA on F-READ.

The octet representation of the transferred data is

unpredictable. It will usually correspond to the data values as stored in the local Real Filestore of the Responder.

A document of type NBS-7 can be accessed as a document of type

NBS-6 (allowed only when reading the file) by specifying document

type NBS-6 with appropriate data type parameters in the <contents

type> parameter on the <F-OPEN request>.

11.2 Access context selection

A document of type NBS-7 may be accessed in any one of the access

contexts defined in the NBS-ordered-flat constraint set. The

presentation data units transferred in each case are those

derived from the structuring elements defined for that access context in ISO 8571-2.

11.3 The INSERT operation

When the <INSERT> operation is applied at the end of file the

transferred material shall be the series of FADUs which would be

9-51
December '89

generated by reading any NBS-7 document with the same parameter

values in access context FA.

9-52
March 1990 (Stable)

I NBS-8 Indexed sequential file

1. Entry Number: NBS-8

2. Information objects

Table 9.11. Information objects in NBS-8

document tjrpe name {iso identified-organization oiw(14)

ftamsig(5) ied(-9999> -organizatton-eode^-t)

document type(5) indexed-file(8)

)

"NBS-8 FTAM indexed file"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14)

ftamsig(5) ted(-9999> -organization -code ft)

abstract syntax(2) nbs-asl(l))

"NBS abstract sjmtax ASl"

{iso standard 8571 abstract-syntax(2) ftarafadu(2)}

"FTAM FADU"

transfer syntax names: { joint-iso-ccitt asnl(l) basic-encoding(l)

) "Basic Encoding of a single ASN.l type"

parameter syntax:

PARAMETERS : := SEQUENCE {DataTypes, KeyType , KeyPosition)

DataTypes : := SEQUENCE OF CHOICE {ParameterO, Parameterl , Parameter2)

KeyType : := CHOICE {ParameterO, Parameterl, Parameter2)

ParameterO, Parameterl, Parameter2, as defined for the

-- document tjrpes NBS-6, NBS-7

KeyPosition: := INTEGER

file model {iso standard 8571 f ile-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set (4)

ordered-flat(3) } "FTAM ordered flat constraint set"

file contents:

Datatypel : := PrimType --as defined in Appendix C.3

Annex -9A ,- -Part -3 Datatype2 ::= CHOICE { Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element } Exit-Subtree-Data-Element }

9-53
March 1990 (Stable)

3. Scope and field of application

The document type defines the contents of a file for storage, for

transfer and access using FTAM.

Note: Storage refers to apparent storage within the Virtual

Filestore

.

4. References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management

5 . Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6 . Abbreviations

FTAM File Transfer, Access and Management

7 . Document semantics

The document consists of zero, one or more file access data units,

each of which consists of zero, one or more data elements. The order

of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the FTAM ordered flat

constraint set (see table 9.11). These definitions appear in ISO

8571-2.

The following additional requirements are specified for the use of

the ordered flat constraint set:

o The FADU identities 'first', 'last', and 'node number' are not required for conformant implementations

o The identities 'next' and 'previous' are allowed for all

FADUs

Each data element is a data type from the set of primitive data types

defined in Appendix C.3 9A,--Parfe-3 of this document. Each data unit

contains the same data element types in the same order as all other

data units. These types and their respective maximum lengths are defined by the <DataTypes> parameter.

The string length field of Parameterl specifies the length of the

value in octets for the INTEGER, BIT STRING and OCTET STRING types.

For character- type data elements, the string-length indicates the

9-5A
March 1990 (Stable)

actual number of characters from the specified character set, not

including any escape sequences or overhead from the character

encoding.

For floating point numbers, finite form, length-1 and length-2

specify the length In bits of mantissa and exponent, respectively.

The length-1 and length-2 values are Irrelevant for the other choices

of floating point numbers.

9-55
March 1990 (Stable)

Each data unit in the file has a key associated with it, which is the

user-coded form of Node Name. The key of each data unit is of the same data type as the key of all other data units in the file and is a single data element from the set of primitive data tjrpes defined in

Appendix C.3 9A,--Part-3.

The type and length of the key are defined by the <KeyType>

parameter.

The primitive data types and minimum size ranges of each unit which

an implementation must accept as a key value are given in the

following table 9.12.

Table 9.12. Datat3rpes for keys

Key Type Minimum Range (octets) Order

ASN.l INTEGER (1-2) increasing numeric value

ASN.l IA5String (1-16) lexical order

ASN.l GraphicString (1-16) lexical order

ASN.l GeneralString (1-16) lexical order

ASN.l OCTET STRING (1-16) increasing value

ASN.l GeneralizedTime increasing time value

ASN.l UniversalTime increasing time value

NBS-ASl FloatingPointNumber increasing numeric value

The position of the key in the data unit is specified by the

<position> parameter.

position = 0 implies the key is not part of the data

position > 0 specifies the actual data element in the data unit.

8. Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically

structured file as defined in the ASN.l module IS08571-FADU in ISO

8571, in which each of the file access data units has the abstract

S3mtactic structure of NBS-ASl as defined by the parameters.

9. Definition of transfer

9 . 1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 9.11, where the PrimType in the

datatype is given by the NBS-ASl definition; or

9-56
December '89

b) Datatype2 defined in table 9.11, the ASN.l datatype

declared as "Data-Element" in the ASN.l module IS08571-FADU.

9.2 Presentation data values

The document is transferred as a series of presentation data

values, each of which is either

a) one value of the ASN.l datatype "Datatypel ,"• carrying one of

the data elements from the document. All values are transmitted in the same (but any) presentation context

defined to support the abstract syntax name "asnamel" or

b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context defined to support the

abstract syntax name "asname2."

Notes: 1. Specific carrier standards may impose additional

constraints on the presentation context to be

used, where the above permits a choice

2. Any document type defined in this entry either

makes no use of Datatype2, or starts with a Datatype2 transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between P-DATA primitives,

are chosen locally by the sending entity at the time of

transmission, and carry no semantics of the document type.

Receivers which support this document type shall accept a document with any of the permitted transfer options (e.g.,

document type parameters and transfer syntaxes)

.

9.3 Sequence of presentation data values

The sequence of presentation data values of type a) and the

sequence of presentation data values of types a) and b) is the same as the sequence of data elements within a Data Unit, and

Data Units in the hierarchical structure, when flattened

according to the definition of the hierarchical file model in ISO

8571-2.

10. Transfer syntcix

An implementation supporting this document type shall support the

transfer syntax generation rules named in table 9.11 for all

presentation data values transferred. Implementation may

optionally support other named transfer syntaxes.

11. ASE specific specifications for FTAM

11.1 Simplification and relaxation

9-57
December '89

11.1.1 Structural simplification

This simplification loses information.

The document type NBS-8 may be accessed as a document type FTAM-3

(allowed only when reading the file) by specifying document type

FTAM-3 in the <contents type> parameter in <F-OFEN request>, and

limiting access context to UA on F-READ.

The octet representation of the transferred data is

unpredictable. It will usually correspond to the data values as stored in the local Real Filestore of the Responder.

A document of type NBS-8 can be accessed as a document of type

NBS-6 (allowed only when reading the file) by specifying document

type NBS-6 with appropriate data type parameters in the <contents

type> parameter on the <F-OPEN request>. The traversal order of

I the FADUs must be maintained.

Note: The traversal order is as reading the file as NBS-8 in

key order.

11.2 Access context selection

A document of type NBS-8 may be accessed in any one of the access contexts defined in the FTAM ordered flat constraint set. The

presentation data units transferred in each case are those

derived from the structuring elements defined for that access

context in ISO 8571-2.

11.3 The INSERT operation

When the <INSERT> operation is applied the transferred material

shall be the series of FADU which would be generated by reading

any NBS-8 document with the same parameter values in access

context FA.

The insertion of a new FADU after an already existing FADU will

be indicated via a diagnostic on TRANSFER-END.

11.4 The EXTEND operation

This operation is excluded for the use with this document type.

9-58
A.8 NBS-9 File directory file

1. Entry Number: NBS-9

2. Information objects

March 1990 (Stable)

9-59
March 1990 (Stable)

Table 9.13. Information objects in NBS-9

document type name { iso identified-organization oiw(14)

ftamsig(5) tedf9999> -organization -eode(-t)

* 4 life LL\^ r \ / X-'i-'i-C? \x d. 1. y \ ^ / / "NBS-9 FTAM file directory file"

abstract syntax names: {iso identified-organization oiw(14)

ftamsig(5) (^9999> -organizafeton-eodefl)

abstract-syntax(2) nbs-as2(2))

"NBS file directory entry abstract sjmtax"

transfer syntax names

{ j oint- iso-ccitt asnl(l) basic-encoding(l)

)

"Basic Encoding of a single ASN.l type"

parameter syntax

PARAMETERS : := [0] IMPLICIT BIT STRING {

-- Kernel group

read-filename (0),

read-permitted-actions (1),

read- contents - type ( 2 )

,

-- Storage group

read-storage-account (3),

read-date-and-time-of -creation (4)

,

read-date-and-time-of -last-modification (5)

,

read-date-and-time-of -last-read-access (6)

,

read-date-and- time -of -last -at tribute -modification( 7)

,

read- identity-of-creator (8),

read- identity-of- last-modifier (9)

,

read-identity-of-last-reader (10)

,

read-identity-of-last-attribute-modifier (11)

,

read-file-availability (12),

read-filesize (13),

read- future- files ize (14),

-- Security group

read-access-control (15),

read- legal-qualifications (16),

Private group

read-private-use (17) )

(Continued on next page.)

9-60
March 1990 (Stable)

Table 9.13. Information objects in NBS-9 continued.

file model {iso standard 8571 file-model(3)

hierarchical ( 1 )

}

"FTAM hierarchical file model"

constraint-set {iso standard 8571 constraint-set (4)

unstructured(l)

)

"FTAM unstructured constraint set"

File contents:

Datatjrpel : := FileDirectoryEntry

--As defined by NBS-AS2 in Appendix A,

--C.4 Part -3 of this document

3. Scope and field of Application

This document defines the contents of a file for transfer (not for

storage) using FTAM.

4. References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management.

5 . Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1

6 . Abbreviations

FTAM File Transfer, Access and Management.

7. Docijment Semantics

The document consists of one file access data unit, which consists

only of zero, one or more data elements of type <FileDirectoryEntry>

(defined in NBS-AS2)

.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the unstructured constraint

set. These definitions appear in ISO 8571-1.

The parameter of the document type is used on <F-OPEN request> to

specify the desired attributes of each of the files on the Filestore,

when reading the document.

8. Abstract syntactic structure

9-61
March 1990 (Stable)

The abstract syntactic structure of the document is a series of file

directory entries , each of which is defined by the

<FileDirectoryEntry> definition in NBS-AS2.

Additional constraints are defined for this document t3^e: File access actions are restricted to Read. File-directory files may not

be Written or Modified (except as a side effect of actions performed

on individual files contained within a file directory)

.

9. Definition of transfer

9.1 Datatype definition

The file consists of zero or more values of Datatypel defined in

table 9.13.

9 . 2 Presentation data values

The document is transferred as a series of presentation data

values. Each presentation data value shall consist of one value

of the ASN.l data type "Datatypel," carrying one of the file

directory entries from the document.

All values are transmitted in the same (but any) presentation

context established to support the abstract syntax name

"asnamel" declared in table 9.13.

9 . 3 Sequence of presentation data values

The sequence of presentation data values is the same as the

sequence of file directory entries within the Data Unit in the

file.

10. Transfer syntax

An implementation supporting this document type shall support

the transfer syntax generation rules named in table 9.13 for all

presentation data values transferred. Implementations shall

optionally support other named transfer syntaxes.

11. ASK specific specifications for FTAM

11.1 Simplification and relaxation

Relaxation is allowed to any bitstring combination of the

document type parameter.

9-62
March 1990 (Stable)

APPENDIX B: CONSTRAINT SETS

LJL NBS Ordered flat constraint set

This object with Object Identifier

{iso identified-organization icd(9999) organization-code (1) constralntset(4) nbs-ordered-flat(l)

)

was withdrawn on March 16, 1990. It was replaced with the object NBS

Ordered flat constraint set with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) constraint-set (4)

r;i3S-ordered-flat(l)

)

defined in chapter 9, B.2.

9-62-1

J.une 1990 (Stable)

Lul NBS Ordered flat constraint set definition

1. Field of application

The NBS -ordered flat constraint set applies to files which are structured into a sequence of individual FADUs and to which access may be made oh an FADU basis by position in the sequence.

2. Basle constraints

9-6 3
June 1990 (Stable)

Table 9.14. Basic constraints for NBS Ordered flat

Constraint set descriptor "NBS ordered flat constraint set"

Constraint set identifier {iso identified-organization oiw(14)

ttamsigQ

J

) constraint-set (4) nbs-orderedI iat (. i ; J

Node name None

File access actions Locate, Read, Insert, Erase, Replace

Qualified action None

Available access contexts HA, FA, UA

Creation state Root node without an associated data

unit

Location after open Root node

Beginning of file Root node

End of file No node selected; 'previous' gives last

node in traversal sequence ,' current ' and

'next 'give an error.

Read whole file Read in access context FA or UA with

FADU identity of 'begin'

.

Write whole file (append)

Write whole file (replace)

Transfer the series of leaf FADUs which

would be generated by reading the whole

file in access context FA; perform the

1"'ran«;fet" with an FADU identitv of 'end'

and a file access action of 'insert'.

Transfer the series of leaf FADUs which

would be generated by reading the whole

file in access-context HA; perform the

transfer with FADU identity 'begin' and

file action of 'replace'.

3. Structural constraints

The root node shall not have an associated data unit; all children of

the root node shall be leaf nodes and may have an associated data

unit; all arcs from the root node shall be of length one.

4. Action constraints

Insert

The <Insert> action is allowed only at the end of file. If

the FADU identity is 'end' the new node is inserted

9-64
June 1990 (Stable)

following all existing nodes in the file. If the FADU identity

is 'node nvimber' , the number must be at least one greater than

the node number of the last existing node. Any nodes between the

last existing node and the new node are empty, i.e., nodes

without data. If the FADU identity is a 'node number' not

greater than that of the last existing node, an error will occur. The location following <insert> is 'end'.

Erase

The Erase action is only allowed at the root node to empty

the file, with FADU identity of 'begin'. The result is a solitary root node without an associated data unit.

Note: It is the intention when using this constraint set to allow

for emptying an FADU, i.e., leaving an FADU with a DU of

data length 0 (or without a DU) ; afterwards data may be

reinserted into this hole. In order to empty an FADU, the

<Replace> operation may be used with new data of length zero

(or with an FADU whose <data exists> bit is set to 'false'

and no DU) . Refilling the hole is accomplished by a <Replace> operation with the new DU (or with the new FADU,

whose <data exists> bit is set to 'true' and the new DU)

.

Identity constraints

The FADU identity associated with the file action shall be one of the

identities 'begin', 'end', 'first', 'last', 'current', 'next',

'previous' or a 'node number' greater than or equal to one. The

actions with which these identities can be used are given in the

following table.

Table 9.15. Identity constraints in NBS Ordered flat

Action Begin End First Last Current Next Previous Node No

.

Locate valid valid valid valid valid valid valid valid

Read whole leaf leaf leaf leaf leaf leaf

Insert leaf leaf

Erase whole

Replace whole leaf leaf leaf leaf leaf leaf

9- 65
June 1990 (Stable)

APPENDIX C: ABSTRACT SYNTAXES

C.

1

Abstract Syntax NBS-ASl

This object with Object Identifier

{iso identified-organization icd(9999) organizatlon-code(l) abstractsyntax(2) nbs-asl(l))

was withdrawn on March 16, 1990. It was replaced with the object

Abstract syntax NBS-ASl with the Object Identifier

{iso identified-organization oiw(14) ftainsig(5) abstract- syntax( 2)

nbs-asl(l)

)

defined in chapter 9, C.3.

C.2 Abstract Syntax NBS-AS2

This object with Object Identifier

{iso identified-organization icd(9999) organization-code (1) abstractsyntax(2) nbs-as2<2))

was withdrawn on March 16, 1990. It was replaced with the object

Abstract syntax NBS-AS2 with the Object Identifier

{iso identified-organization oiw(14) ftamsig(5) abstract-syntax(2)

nbs-as2(2)

)

defined in chapter 9, C.4.

9-65-1

March 1990 (Stable)

I C. 3

Part -3 ^ - -Abstract -SyntaxesAbstract Syntax NBS-ASl definition

Abstract syntax name { iso identified-organization oiw(14) ftamsig(5)

iedf9999> -organization-eode(^t) abstract-syntax(2)

nbs-asl (1)

}

"NBS abstract syntax ASl"

This is an abstract syntax for the set of presentation data values, each

of which is a value of the ASN.l type NBS-ASl . PrimType

NBS-ASl DEFINITIONS : BEGIN

PrimType : := CHOICE {

IRV

Float ingPointNumber

INTEGER,

BIT STRING,

BOOLEAN

,

lASString,

Graphic String,

GeneralString,

OCTET STRING,

UTCTime

,

GeneralizedTime

,

NULL,

FloatingPointNumber )

The support for lASString is the ISO 646,

GO character set and the ISO 646, IRV CO

set

The minimum level of support for

GraphicString is the ISO 646, IRV GO

character set and the 8859-1 GO and Gl sets

The minimum level of support for

GeneralString is the ISO 646, IRV GO

character set and the 8859-1 GO and Gl

character sets, and ISO 646, IRV CO set.

[PRIVATE 0] CHOICE { finite [0] IMPLICIT SEQUENCE

{ Sign,

mantissa BIT STRING,

first bit must be 1 exponent INTEGER)

,

infinity [1] IMPLICIT Sign,

signalling-nan [2] IMPLICIT NaN,

quiet-nan [3] IMPLICIT NaN, zero [4] IMPLICIT NULL )

Sign

NaN

END

: := INTEGER { positive (0), negative (1) )

: := INTEGER

9-66

i
March 1990 (Stable)

For this abstract syntax the following transfer syntax can be used

{ joint-iso-ccitt asnl(l) basic-encoding(l)

)

"Basic Encoding of a single ASN.l type"

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

.

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.

5. A minimxim length range (in bits) is required for the

components of <FloatingPointNumber>, as follows: mantissa

1-23 bits, and exponent 0-8 bits.

I Abstract Syntax NBS-AS2 definition

I Abstract S3nitax name: { iso identified-organization oiw(14)

I ftamsig(5) iedf9999)- -organization-eode(-l:)

abstract-syntax(2) nbs-as2(2) }

"NBS file directory entry abstract syntax"

This is an abstract syntax for the set of presentation data values, each

of which is a value of the ASN.l Type NBS-AS2 , FileDirectoryEntry

.

NBS-AS2 DEFINITIONS : :=

BEGIN

FileDirectoryEntry : :=[PRIVATE 2] Read-Attributes

Read-Attributes : :=IS08571-FTAM. Read-Attributes

END

For this abstract syntax the following transfer syntax will be used

{ joint-iso-ccitt asnl(l) basic-encoding(l) )

"Basic Encoding of a single ASN.l type"

I c . 5 Abstract Syntax "FTAM unstructured text abstract syntax"

This abstract syntax is defined as DataTypel (File Contents) in table 19

of ISO 8571-2, Annex B.

I c . 6 Abstract Syntax "FTAM unstructured binary abstract syntax"

9-67
March 1990 (Stable)

This abstract syntax is defined as DataTypel (File Contents) in table 21

of ISO 8571-2, Annex B.

Part -4 ^ -(-deteted)

(former Part 4 deleted)

9-68
10.

March 1990 (Stable)

ISO FILE TRANSFER. ACCESS AND MANAGEMENT PHASE 3

Editor's Note: The "NBS" designation remains in effect for

document types, abstract syntaxes, and constraint

sets defined in all FTAM agreements up to 1/1/89.

After 1/1/89, any new functionality references the

"NIST" designation. This is to reflect the change

in identifying organization from "NBS" to "NIST."

10.1 INTRODUCTION

This section contains Implementors Agreements based on ISO 8571 File

Transfer, Access and Management. These Agreements define enhancements

to the Stable FTAM Implementation Agreements for OSI Protocols,

Version 1, Edition 1, December 1987 (FTAM Phase 2 Agreements, NBS

500-150), including all their subsequent Errata changes as specified

in Version 3, Edition 1 (NIST Special Publication 500-177, this

document ch. 9)

.

Therefore it is assumed that the reader is familiar both with the

contents of the base standard ISO 8571 and its underlying layers, and

also with the above-mentioned NIST FTAM Phase 2 specifications.

Phase 2 Agreements define six Implementation Profiles which are Tl

,

T2 , T3 , Al , A2 , and Ml. In order to avoid ambiguity when referring to

these Implementation Profiles the above designations will apply only

to Phase 2 functionality, references to Phase 3 enhanced

Implementation Profiles will be by the addition of a'. 3', i.e., T1.3,

T2.3, T3.3, A1.3, A2 . 3 , and Ml . 3

.

The following sections specify the functionality of NIST OIW FTAM

Phase 3

.

o Sections 10.2 and 10.9 specify the technical details of FTAM

Phase 3 which are defined in addition to the functionality of

FTAM Phase 2. Included is also a status -overview regarding

statements on Phase 2/Phase 3 compatibility and interworking.

o Appendix A is a Profile Requirements List for the Implementation

Profiles Tl.3, T2.3, Al . 3 and Ml . 3 , summarizing all features of

FTAM Phase 3, including those of FTAM Phase 2. This Profile

Requirements List is fully based on the FTAM PICS Proforma ISO

DIS 8571-5.

o Appendix B is an index of Object Identifiers. It is the official

NIST OIW REgister of NIST OIW defined FTAM objects. It contains

the Object Descriptors and Object Identifiers for these objects,

including a reference to the section in the NIST OIW Stable

Agreements where the respective object is being defined.

10-1
March 1990 (Stable)

o Appendices C, D, and E provide definitions for additional

document types, constraing sets and abstract syntaxes.

10.2 SCOPE AND FIELD OF APPLICATION

These Phase 3 Agreements specify additional functionality to the FTAM

Phase 2 Agreements. These additional functions include:

o Further specifications of document types,

o Specification for Restart Data Transfer and Recovery functional

units

,

o Specification of FADU Locking functional unit, and

o More details on Access Control and Concurrency Control.

All Phase 2 systems are upward compatible to a Phase 3 system and can

therefore interwork with it, if the additional functions are negotiated out (e.g., use of Recovery) or not used for the

interconnection (e.g., additional features for document types).

10.3 STATUS

These FTAM Phase 3 Agreements were completed December 15, 1989. No

further enhancements will be made to this version (see also next

section ERRATA)

.

The following tables summarize the functions and features which are defined for FTAM Phase 3 in addition to the FTAM Phase 2

specifications. They also state the degree of possible interworking

and the backward compatibility.

10-2
March 1990 (Stable)

Table 10.0(a). Phase 2/Phase 3 Interworking

Additional Requirements

in FTAM Phase 3 Backward Compatibility

to FTAM Phase 2

FTAM-1: Graphics tring, VisibleString

FTAM-2: VisibleString

concurrency- control parameter for Initiator

create-password parameter for Initiator

Profile Ml . 3 : Requires support of

(1) -T service class including Limited File

Management FU, Enhanced FM FU;

TM service class including Enhanced

FM FU or

(2) -A service class including Limited File

Management FU, Enhanced FM FU

full backward compatibility if the additional

features of Phase 3 are not being used (character

sets in FTAM-1, -2), or not requested by an Initiator (functional

units) or not required

by a Responder

(parameters) not requested

by an Initiator

(functional units)

10-3
March 1990 (Stable)

Table 10.0(b). Phase 2/Phase 3 Interworking (continued)

Additional Optional Features

in FTAM Phase 3

Backward Compatibility

to FTAM Phase 2

FTAM-2: Generals tring, lASString

FTAM4

NBS-8 in T2.3, Al .

3

NBS-9 in A1.3, A2.3

NBS-10

NBS-11

NBS-12

Recovery functional unit

Restart-data- transfer functional unit

FADU- locking functional unit and FADUlock parameters in Al . 3 , A2 .

3

concurrency-control parameters for

Responder

full backward compatibility if the additional

features of Phase 3 are not requested, negotiated

out or not being used

create -password parameter for Responder

location-field of access -control element

suggested-delay term of diagnostic

parameter supported conditionally on Recovery or -Restarfe-data-transfer functional units

10-4
March 1990 (Stable)

Table 10.0(c). Phase 2/Phase 3 Interworking (continued)

Relaxation for FTAM Phase 3 to FTAM Phase 2

Profiles A1.3, A2.3 do not require

transfer service class

no minimum requirement for maximum- stringlength parameters for document types

if T service class not

being used

if a Phase 3 system stays

below this minimum

requirement

10.4 ERRATA

Mn CW I7PRATA TVPF

REFERENCED

nnr'TTvrPMT UULiUriEjJN i DJljO i lUJN

CP 3/90-1 TECHNICAL NIST-SP

500-177

A. 9, A. 13

B. l, B.2.1

NBS-6, NBS-7,

NBS-8, NBS-9,

NBS-ASl, NBS-AS2,

NBS-orderedflat constraint

set with Obj Id.

using icd(9999)

withdrawn.

Above FTAM objects

newly defined with

Obj . Id. using

oiw(14) ftamsig(5)

CP 3/90-3 EDITORIAL Appendices

C, D, E

structuring into

subsections, all

references to these

definitions updated accordingly

CP 3/90-5 TECHNICAL 10.8.5.2 support of

suggested- delay

field of diagnostic

not conditional

on Restart-datatransfer

10-5
March 1990 (Stable)

10. 5 CONFORMANCE

In addition to the specific requirements specified in the following

subsections, conformance to this Phase 3 specification requires

o conformance to ISO 8571: 1988

o conformance to Phase 2 FTAM, unless specified otherwise in this

chapter 10.

10.5.1 Conformance for Access Profiles

The access Profiles Al . 3 and A2 . 3 do not include the requirement

for transferring files using the File Transfer service class.

10.6 ASSUMPTIONS

FTAM Phase 3 Agreements specify additional functionality to the

Implementation Profiles Tl , T2 , T3 , Al , A2 , and Ml as defined in the

FTAM Phase 2 Agreements. So all definitions and requirements for

these Implementation Profiles apply also to the Phase 3 Agreements.

10.7 FILESTORE AGREEMENTS

10.7.1 Document Types

In addition to the Phase 2 Document Type Agreements the document

types FTAM-4 (see ISO 8571-2, Annex B) and NBS-10, NBS-11, NBS-12

(see Appendix C) are defined for optional support.

Table 10.1 gives the support levels for all document types with

respect to the Implementation Profiles,

For FTAM-1, FTAM-2, FTAM-3 and FTAM-4 the supported parameter

values for <universal class number> and <string significance>,

respectively are listed. Other values are outside the scope of

these Agreements. No restriction or minimum requirement is

defined for the <maximum string length> parameter of these

document types

.

10-6
December '89

Table 10.1. Implementation Profiles and Document Types

(a) FTAM-1 Through FTAM-4

Implementation

Profile

(Note 1)

Document

Type

Universal

Class Number

(Notes 1, 3, 4, 5)

String

Significance

T1.3, T2.3, T3.3,

A1.3, A2.3

FTAM-1 Graphic String (25) 'variable' 'fixed'

VisibleString (26) 'variable' 'fixed'

GeneralString (27) ' not- significant

lASString (22) ' not- s ignif icant

T2.3, T3.3, A1.3,

A2.3

FTAM-2 GraphicString (25) ' not- significant

VisibleString (26) ' not- significant

[GeneralString (27)] ' not-significant

[IA5String (22)] 'not- significant

T1.3, T2.3, T.3.3,

A1.3, A2.3

FTAM-3 ' not-significant

[T2.3], [T3.3],

[A1.3], [A2.3]

FTAM-4 ' not- s ignif icant

10-7
December '89

Table 10.1. Implementation Profiles and Document Types

(b) NBS-6 Through NBS-11

Implementation

Profile (Note 1)

Document

Type

[T2.3] , T3.3,

(Al.3] . A2.3

NBS-6

[T2.3] . T3.3.

[Al.3] . A2.3

NBS-7

(T2.3] , T3.3

(Al.3] , A2.3

NBS-8

[T1.3], [T2.3].

[T3.3], [Al.3] , [A2.3]

NBS-9

[T2.3], [T3.3]

[Al.3], (A2.3]

NBS-10

[T2.3], (T3.3]

[Al.3], [A2.3]

NBS-11

Table 10.1. Implementation Profiles and Document Types

(c) NBS-12

Implementation

Profile

(Note 1)

Document

Type

Universal

Class

Number

Character-Set

Escape Sequences

as defined for

Reg. Numbers

CO GO Gl

StringSignificance

[T2.3]. [T3.3]

[Al.3], [A2.3]

NBS-12 lASString [22] (parameter absent) ' variable

' fixed'

See

Note 6 GraphicString(25] (parameter absent) 'variable' 'fixed'

GraphicString[25] 6 100 'variable' ' fixed'

VisibleString[26] (parameter absent) 'variable

' fixed'

GeneralString[27] (parameter absent) 'variable' fixed'

GeneralString[27] 1 6 100 'variable

' fixed'

1

10-8
December '89

Notes: 1. Brackets around a Profile designator or a parameter value indicate that the respective

document type or parameter value is optionally

supported in this Implementation Profile.

2. The support level for document types in

Implementation Profile Ml . 3 depends on the T- or

A- Implementation Profile, in conjunction with

which Ml . 3 is implemented.

3. The support for IA5 String is the ISO 646, IRV GO

character set and the ISO 646, IRV CO set.

4. The minimum level of support for Graphic String is

the ISO 646, IRV GO character set and the 8859-1

GO and Gl sets.

5. The minimum level of support for General String is

the ISO 646, IRV GO character set and the 8859-1

GO and Gl sets, and ISO 646, IRV CO set.

6. If the Character- Set parameter is absent, the

following defaults apply:

Universal -Class -Number Default Registration Numbers

CO GO Gl

lASString [22]

GraphicString [25]

VisibleString [26]

GeneralString [27]

1 2

2

2

1 2

Character-Sets and Escape Sequences:

Registration Content Escape

Number Sequence

1 CO set of ISO 646 ESC 2/1 4/0

2 ISO 646, IRV

6 ISO 646, USA Version-X 3.4 - 1968 ESC 2/8 4/2

(Left-hand part of ISO 8859-1)

100 Right-hand part of Latin Alphabet No 1 ESC 2/13 4/1

ISO 8859-1, ECMA-94

10.7.2 FADU Identities

10-9
December '89

In addition to the Phase 2 FADU Identity Agreements the following is

specified:

For the document type NBS-11 used in conjunction with the

Transfer service class or the Transfer and Management service

class, the support of the FADU identities of 'current', 'next',

'previous' and 'end' is outside the scope of these Agreements.

10.7.3 Access Control Attribute

The location field of access control element is optionally supported.

It is the implementor ' s choice which combinations of fields in an access control element are supported. The ACE combination should be

stated in the PICS.

10. 8 PROTOCOL AGREEMENTS

10.8.1 Implementation Profile Ml .

3

The functions defined for the Implementation Profile Ml . 3 shall always

be implemented in conjunction with one or more of the Implementation

Profiles T1.3, T2 . 3 , Al . 3 , or A2 . 3 . The service classes and functional

units that shall be implemented are specified in section 10.10,

Appendix A, A. 12.4 and A. 12. 5.

For an implementation supporting the Profile Ml . 3 in conjunction with

Tl . 3 or T2 . 3 , any of the service classes Transfer, Management or (Transfer, Management, Transfer-and-Management) may be requested and

any of the classes Transfer, Management, Transfer-and-Management may be

responded on F- INITIALIZE

.

For an implementation supporting the Profile Ml . 3 in conjunction with

Al . 3 or A2 . 3 , any of the service classes Access or Management may be

requested and responded on F- INITIALIZE

.

10. 8 .

2

Functional Units

For FTAM Phase 3 implementations Recovery and Restart Data Transfer are optionally supported.

FADU locking is optionally supported for Implementation Profiles Al .

3

and A2.3.

10.8.3 Implementation Information Parameter

10-10
March 1990 (Stable)

In addition to the Agreements as specified for FTAM Phase 2, section

9.12 , the following value is defined

NBS- Phases.

10.8.4 F- Check

In order to maximize interoperability, implementations of FTAM service

providers should not restrict the amount of data transmitted between

successive F-CHECK requests to a single quantity. Variations in the

amount of data transmitted between checkpoints may be required to

accommodate differences in real end systems supporting FTAM Virtual

Filestores and/or in the communications media underlying FTAM

associations. It is required that all FTAM implementations are able to

receive at least one PSDU between checkpoints.

10.8.5 Error Recovery

Procedures for Class I, II and III errors are defined and supported for

FTAM Phase 3 implementations. It is the implementor ' s choice whether

to handle class I errors using F-RESTART PDUs or whether to use the

class II error procedure.

10.8.5.1 Docket Handling

When a class III error occurs, the length of time a docket is

maintained is determined by the local system. Recovery from a class III error is only possible as long as both end systems

maintain the docket.

It is also a local decision how many dockets can be maintained

simultaneously.

10.8.5.2 Parameters for Error Recovery

o The semantics of the <FTAM quality of service> parameter is as defined in ISO 8571, including the local knowledge of

FERPM.

o No minimum requirement for the <checkpoint window> parameter

or the checkpoint size is defined.

o For the <recovery mode> parameter of F-OPEN, the values

'none' and ' at-start-of-transfer ' are supported. The value

' at-any-active-checkpoint ' is optionally supported. If

recovery mode 'at-start-of-transfer' is negotiated, no F10-11
March 1990 (Stable)

CHECK shall be issued. When recovering at the start of the

transfer, the <recovery point> value of 0 shall be used.

o It is required that Responders implementing the Restart-datatransfer or the Recovery functional unit must be able to

negotiate <recovery mode> parameter to a value other than

' none '

.

o For the <diagnostic> parameter of F- INITIALIZE , F-P-ABORT and

F-RECOVER PDUs, the term <suggested delay> shall be supported

if the Recovery or -Resfeart-data-fcifansfer functional units is are implemented. The Basic FERPM should wait at least the

amount of time as given by the <suggested delay> term before

attempting to recover.

10.8.6 Concurrency Control

10.8.6.1 Concurrency Control to whole file

The <concurrency control> parameters of F-SELECT, F-CREATE and FOPEN with or without the <access control> attribute of Security

Group are supported for Initiators and optionally supported for

Responders

.

If supported by a Responder, details of their possible usage is a local matter and shall be specified in the PICS

.

Default values for concurrency control are as specified for FTAM

Phase 2 Agreements

.

No minimum requirement is defined for <concurrency control>

parameter values.

For a first accessor either the specified concurrency locks or the

default values are assigned. For a subsequent accessor the access

to a file is granted only if this concurrency control requirement,

as specified in this concurrency control parameter or given by the

default values, can be met. Otherwise the subsequent request

shall be rejected.

10.8.6.2 FADU Locking

FADU locking functional unit and the respective <FADU lock>

parameters are optionally supported for the Implementation

Profiles Al . 3 and A2 . 3

.

10-12
March 1990 (Stable)

It is understood that ISO 8571-4 Clause 18.4 also applies to FADU

locks; that means that as long as a docket is maintained, FADU

locks locking any FADUs recorded in that docket should be

maintained

.

10 8 . 7 Create Password

The <create password> parameter for an implementation acting as an Initiator is supported. This parameter is optionally supported for an implementation acting as a Responder.

10.8.8 Initiator Identity. Passwords and Account

An Initiator must be capable of sending and not sending the parameters

<initiator identity>, <filestore password>, <access passwords> and

<create password> to satisfy the requirements of the Responder.

The contents of the <initiator identity>, <filestore password>,

<access passwords>, <create password> and <account> parameters shall be

in the convention of the responding implementation.

10.9 Range of Values for Integer-Type Parameter

In addition to the parameters specified for FTAM Phase 2 under the same heading, the parameters

F-RECOVER request

bulk- transfer-number

NBS-AS3

NBS -Node -Name

starting- fadu

fadu-count

may be encoded so that the length of its contents octets is no more than

eight octets.

10-13
APPENDICES

March 1990 (Stable)

APPENDIX A: PROFILES REQUIREMENTS LIST FOR NIST OIW FTAM PHASE 3

APPENDIX B: NIST OIW REGISTER OF FTAM OBJECTS

APPENDIX C: DOCUMENT TYPES

APPENDIX D: CONSTRAINT SETS

APPENDIX E: ABSTRACT SYNTAXES

10-14
March '90

I APPENDIX A : PROFILES REQUIREMENTS LIST FOR NIST OIW FTAM PHASE 3

A.O Introduction

This appendix to NIST FTAM Phase 3 Agreements defines a Profile Requirements List (PRL) for the Implementation

Profiles

T1.3 - Simple File Transfer T2.3 - Positional File Transfer A1.3 - Simple File Access

Ml. 3 - Management

This appendix specifies the constraints and characteristics of NIST OIW FTAM Phase 3 on what shall or may

appear in the supplier columns of an FTAM Phase 3 PICS. This appendix is completely based on ISO 8571-5. It uses only a selection of the tables from ISO 8571-5 which are necessary for the specification of the FTAM Phase 3

status, and retains their numbering, in order to facilitate for a supplier to fill in the respective PICS Proforma.

This appendix is a summary of all definitions of FTAM Phase 3 as they appear in the Stable implementation

Agreements for OSI Protocols, Version 3 Edition 1, December 1989, chapters 9 and 10.

A.0.1 Conformance requirement of Base Standards

The D-column of sections A.I to A. 13 specifies the conformance requirement of the base standards ISO 8571, as

written in ISO 8571-5. The definitions apply as defined in ISO 8571-5 clause 8.1 : m - mandatory support o - optional support

f - full support of attributes p - partial support of attributes

- not applicable

A single value in the D-column applies to the Initiator role of a system as well as to the Responder role. If two

values are specified in the D-column separated by a space, they apply to the Initiator (I) role and to the Responder

(R) role, respectively.

A.0.2 Conformance requirement of Profiles

The Conformance requirement of the Implementation Profiles is specified in the 'Profiles' column/columns in sections A.I to A. 13. The following convention is applied for this purpose :

0 a 'PROFILES' column is valid for all Profiles T1 .3, T2.3, A1 .3 and Ml .3

0 if different conformance requirements apply to different Profiles, separate columns are included in the tables, each

bearing the corresponding Profile name as its heading, or separate tables for these Profiles are used

o a single value in these columns applies to the Initiator as well as to the Responder role of an implementation

10 - 15
December '89

o if two values are specified in a column separated by a space, they apply to the Initiator (I) role and to the Re- sponder (R) role, respectively.

For the conformance requirements of the NIST FTAM Phase 3 Profiles the following abbreviations are used,

mandatory; m : This is a mandatory or optional feature in the base standard. It shall be supported, i.e., its syntax and procedures

shall be implemented as specified in the base standard or in FTAM Phase 3 by all implementations claiming I conformance to the Profile.

However, it is not a requirement that the feature shall be used in all instances of communication, unless mandated

by the base standard or stated otherwise in FTAM Phase 3.

For fully supported attributes, this implies that at least the minimum range of attribute values, as defined in ISO

8571-2, shall be supported unless stated otherwise in FTAM Phase 3.

Also for features which are optional in the base standard, conformant implementations shall be able to interwork

with other implementations not supporting this feature.

The support of a feature can be conditional, depending on the support of a class of features to which it belongs,

e.g., an attribute in an attribute group, a parameter in a PDU, a PDU in a functional unit.

optional; o

It is left to the implementation as to whether this feature is implemented or not.

If an attribute group with a support level of 'o' is chosen to be supported, then all the attributes in this group that are

classified as 'm' shall be supported.

The support for PDUs is determined by the negotiation of functional units when the connection is established.

If a parameter is optionally supported, then its syntax shall be implemented, but it is left to each implementation

whether its procedures are implemented or not.

When receiving an optional parameter which is not subject of negotiation and is not supported by the Receiver, the Receiver shall at least inform the Sender by informative diagnostic and interworking shall not be disrupted.

conditional; c : This feature shall be supported under the conditions specified in FTAM Phase 3. If these conditions are not met, the

feature is outside the scope of the Profile.

excluded; x : This feature is excluded from the Profile. The implementor's answer in the PICS shall always be 'no',

outside the scope; i : This feature is outside the scope of the Profile, i.e., it may be ignored, and will therefore not be subject of a Profile conformance test. However the syntax of all parameters of supported PDUs shall be implemented, even if their procedures are not (i.e., the Receiver shall be able to decode the PDU).

not applicable; -

This feature is not defined in the context where it is mentioned, e.g., a parameter which is not part of the respective

PDU. The occurrence of 'not applicable' features is mainly due to the format of the tables in the Phase 3 Profiles Requirements List.

10 - 16
A.I (void)

A.2 (void)

Section 1 December 1989

Section 2: General ISO 8571 Detail

A.3 ISO 8571 Protocol versions

FTAM protocol version number(s) One

A.4 ISO 8571 Addenda

ISO 8571-1 —

ISO 8571-2

ISO 8571-3

ISO 8571-4

ISO 8571-5

A.5 Defect report numbers and amendments

ISO 8571-1 —

ISO 8571-2

ISO 8571-3 —

ISO 8571-4

ISO 8571-5

A.6 Global statement of conformance

Does FTAM Phase 3 conform to ISO 8571 ? yeS

10 - 17
December 1989

A.7 Initiator / Responder capability

ROLES D PROFILES

1 R

1 Sender 0 o o

2 Receiver 0 o o

NOTE - See section 9.18.1

A.8 Application Context Name details

1 ISO 8571-4 defines a value for a simple transfer mechanism. Other values are not defined for FTAM Phase 3

(see 9.5{9)).

10-18
March '90

Section 3 : Syntax Detail

A.9 Abstract syntaxes

Object Descriptor Object Identifier D T1.3 T2.3 A1.3 M1.3

FTAM PCI (iso standard 8571 abstract-syntax(2)

ftam-pci(1)

}

m m m m m

FTAM FADU {iso standard 8571 abstract-syntax(2)

ftam-fadu(2)

}

0 1 m m i

{joint-iso-ccitt association-control(2)

abstract-syntax(l) apdus(O) versionl(l)

}

m m m m m

FTAM unstructured

text abstract syntax

{iso standard 8571 abstract-syntax(2)

unstructured-text(3)

}

0 m m m

FTAM unstructured

binary abstract syntax

{iso standard 8571 abstract-syntax(2)

unstructured-binary(4)

}

0 m m m

NBS file directory

entry abstract syntax

{iso identified-organization oiw(14) ftamsig{5)

abstract-syntax(2) nbs-as2(2)

}

- c c c -

NBS abstract syntax AS1{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-as1{1)

)

- c c •

NBS random access node name abstract syntax{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-node-name(3)

)

i csee 10.9c

NBS random binary access file abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-random-binary(4)

}

i c 0

NBS simple text

abstract syntax

{iso identified-organization oiw(14) ftamsig(5)

abstract-syntax(2) nbs-simple-text(5)

}

i c c

NOTES

1 Tfie abstract syntaxes wfiich are supported in ttie Implementation Profile M1.3 depend on the T-or A-Profile in conjunction with which Ml.3 is implemented.

2 The support requirements for the conditional abstract syntaxes depend on the constraint sets and document types which are implemented (see clause A. 13).

3 ISO 8571 requires the presence of the transfer syntax derived from the "Basic Encoding of a single ASN.1 type "{joint-iso-ccitt asnl (1) basic-encoding (1)} encoding rules for transfer of the "FTAM PCI" and the "FTAM FADU" abstract syntaxes. Implementation detail of this transfer syntax, and other transfer syntaxes supported, is specified in the PIGS of ISO 8823.

10 - 19
December '89

Section 4 : Virtual Filestore Detail

A.10 Virtual filestore

This clause details the conformance to the file model, file attribute support and to file structure support.

A. 10.1 File model

FILE MODEL D PROFILES

R

1 Hierarchical 0 m

Other models i

A.I 0.2 Attributes

A.1 0.2.1 Attribute groups ,

ATTRIBUTE GROUP NAME D PROFILES

1 Kernel m m

2 Storage 0 o

3 Security 0 o

4 Private 0 .

A.10.2.2 Attribute values

KERNEL GROUP

(INITIATOR)

D PROFILES

1 full RANGE OF VALUES

1 Filename f m see A. 10.2.

3

2 Permitted Actions f m

3 Contents Type f m see A. 12.7

KERNEL GROUP

(RESPONDER)

D PROFILES

R full RANGE OF VALUES

4 Filename f m see A. 10.2.3

5 Permitted Actions f m

6 Contents Type f m see A.I 2.7

10 - 20
December 1989

STORAGE GROUP

(INITIATOR)

D PRORLES

1 full lull RANGE OF VALUES

t

1 m

8 Date and time of creation f m

9 File availability f m

10 Future filesize f m see 9.17.9

NOTE - An initiator shall not partially support attributes

STORAGE GROUP D PRORLES

R full P partial rlMMVJC Wl VMI.IJCO

11 Storage account P o 0

12 Date and time of creation P o o

13 Date and time of last modification P o 0

14 Date and time of last read access P o 0

15 Date and time of last attribute modification P o o

16 Identity of creator P o 0

17 Identity of last modifier P o 0

16 Identity of last reader P o 0

ie Identity of last attribute modifier P o 0

20 File availability P m X

21 Flleuze p m X see 9.17.9

22 Future filesize P o o see 9.17.9

SECURITY GROUP

(INITIATOR)

D PROFILES

1 full RANGE OF VALUES

23 Access control f m see A 12.2

24 Legal qualifications f m

NOTE - An initiator shall not partially support attritxites

SECURITY GROUP

(RESPONDER)

D PRORLES

R full R partial RANGE OF VALUES

25 Access control P tn X see A. 12.2. 9.9.2

26 Legal qualifications P o o

10-21
December 1989

A.1 0.2.3 Filename detail

See section 9.9.1

A.10.3 File Structures

A.I 0.3.1 Constraint sets

CONSTRAINT SET NAME D T1.3 T2.3 A1.3 M1.3

Unstructured 0 m m m

Sequential Rat 0 m m

Ordered flat 0 o o

Ordered flat with unique names 0 o o

Ordered hierarchical 0 1 1

General hierarchical 0 1 1

General hierarchical with unique names 0 1 1

NBS ordered flat o o

NBS random access o o

A. 10.3. 2 File and filestore actions

A.10.3.2.1 Filestore Actions

Support for filestore actions is dependent upon the functional units implemented (see A.12.4 and A. 12.5)

A.I 0.3.2.2 File Actions -

CONSTRAINT SET

RESPONDER

unstructured

ACTION D T1.3

Locate

Read 0 o

Insert

Replace 0 o

Extend 0 o

Erase 0 1

10-22
December 1989

CONSTRAINT SET

RESPONDER unstructured sequential

f In9 iiai

ordered

(tat

ordered fiat with unique nameaNBS

ordered

nai

NBS

random

access ACTION D T2.3 D T2.3 D T2.3 D T2.3 D T2.3 0 T2.3

7 Locate 0 1 0 1 0 I 1 i

8 Read O O 0 o 0 o 0 o o o

• Insert 0 o 0 o 0 o o o

10 Replace 0 o 0 o 0 o o o

11 Extend 0 o 0 o o o

12 Erase 0 1 o 1 0 1 0 ! 1 1

CONSTRAINT SET

RESPONDER unstructured sequential

flat

ordered

flat

ordered flat with unique namesNBS

ordered

flat

NBS

random

access ACTION 0 A1.3 D A1.3 0 A1.3 D A1.3 D A1.3 0 A1.3

Locate 0 o 0 o 0 o o o

Read 0 o 0 o 0 0 0 o o 0

Insert 0 o 0 o 0 o o o

Replace 0 o 0 o 0 o o o

Extend 0 o 0 o 0 o

Erase 0 0 0 o 0 0 0 © o o

NOTE • File actions are not defined in implementation Profile M1.3

10-23
December 1989

A.1 0.3.2.3 Access contexts supported

CONSTRAINT SET

RESPONOER unstructured

ACCESS CONTEXT D T1.3

1 US

2 UA 0 m

3 FS

4 FL

s FA

6 HN

7 HA

CONSTRAINT SET

RESPONDER unstructured sequential ordered ordered flat NBS NBS

with unique ordered random

flat flat names fiat access ACCESS CONTEXT D T2.3 D T2.3 D T2.3 D T2.3 D T2.3 D T2.3

US

UA 0 m o m o m o m m m

FS

FL

FA 0 m 0 m 0 m m

HN

HA 0 o 0 o o

10-24
December 1989

CONSTRAINT SET

RESPONDER unstructured sequential ordered ordered flat NBS NBS

with unique ordered random

flat flat names flat access ACCESS CONTEXT D A1.3 D A1.3 0 A1.3 D A1.3 D A1.3 D A1.3

US

UA 0 m 0 m 0 m o m m m

FS

FL

FA o m 0 m 0 m m

HN

HA 0 o 0 o o

NOTE - The supported access contexts for Impemenlatlon Profile M1.3 are defined In the T- or A-Profile In con|unctlon with which M1.3 is Implemented.

A.I 0.4 Additional information

( Void

)

A.10.5 Override

RESPONDER OVERRIDE D PROFILES

R

1 Create failure 0 m

2 Select old file 0 m

3 Delete and recreate with old attributes 0 o

4 Delete and create with new attributes 0 m

NOTE - The specification of the role of initator is given in section 5 (file protocol detail).

10-25
Section 5 : File Protocol Detail December 1989

A.11 File protocol

See sections 9.5(1) - (3), 9.17

Clauses A.1 1.2 to A. 1 1.24 specify an indication of which PDUs are supported. The conformance requirements for PDUs

are dependent on the particular functional units implemented. PDUs indicated in clauses A.1 1.8 to A.1 1.24 as conditio- nal shall be considered as mandatory when a particular functional unit is implemented, according to the foltowing table.

1

pni k

1

Functional Units

Kernel Read Write Ac- cess LFM EFM Grouping Recovery Restart

F-CREATE A.1 1.8 m

F-DELETE A.1 1.9 m

F-READ-ATTRIB A.11.10 m

F-CHANGE-ATTRIB A.11. 11 m

F-OPEN A.11. 12 m m

F-CLOSE A.11. 13 m m

F-BEGIN-GROUP A.11. 14 m

F-END-GROUP A.11. 15 m

F-RECOVER A.11. 16 m

F-LOCATE A.11. 17 m

F-ERASE A.11. 18 m

F-READ A.11. 19 m

F-WRITE A.1 1.20 m

F-DATA-END A.1 1.21 m m

F-TRANSFER-END A.1 1.22 m m

F-CANCEL A.1 1.23 m m

F-RESTART A.1 1.24 m

NOTES

1 in order to keep the protocol tables compact some forward references have been introduced to clauses which expand upon the

detail of field support.

2 The FTAM protocol will require a number of optional lower layer service to be availat)te (eg Application Entity Titles in ACSE). This requirement is outside the scope of this Profiles Requirements List.

10 - 26
A.11.1 GraphlcString support December 1989

(Void)

A. 11.2 FTAM regime establishment

1 DR

PRORLES

1 R

1 F-JNITlALiZE PDU m m m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 State result - m m all values defined in ISO 8571

3 Action result - m m aJI values defined in ISO 8571

4 Protocol version m m m m see Section 2

5 Implementation information 0 0 o o see A.12.1

6 Presentation context management m m m m see note 1, 9.17.10

7 Service dass m m m m see A. 12.4

• Functional units m m m m see A.12.5

9 Atoibute groups m m m m see A. 10.2

10 Shared ASE information 0 0 i i see 9.5(8)

11 FTAM Quality of Service m m m m see A. 12.8

12 Contents type list 0 0 m m see A.12.7.1. 9.18.4

13 Initiator identity 0 m see 9.16.1. 9.18.4. 10.8.8

14 Account 0 o see 9.18.4. 10.8.8

15 Filestore password 0 m see A.12.11, 9.16.1. 10 8.8

16 Diagnostic 0 m see A, 12.6, 9.13, 10.8.5.2

17 Checkpoint window m m m m see note 2, 10.8.5.2

NOTES

1 The values available for the presentation context management field depend upon the functional units implemented in ISO 8823.

2 Checkpoint window field is indicated as mandatory in accordana^ith ISO 8571-4. The field is defaulted to the value 1

10-27
December 1989

A.11.3 FTAM regime termination (orderly)

D

1 R

PROFILES

1 R

t F-TERMINATE PDU m m m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Shared ASE information 0 0 1 1 see 9.5 (8)

3 Charging - 0 o see A.12.10

A.1 1.4 FTAM regime termination (abrupt) by service user

D PROFILES

1 F-U-ABORT PDU m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result m m all values defined in ISO 8571

3 Diagnostic 0 m see A.12.6. 9.13

A.11.5 FTAM regime termination (abrupt) by service provider

D PRORLES

1 F-P-ABORT PDU m m

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result m m all values defined in ISO 8571

3 Diagnostic 0 m see A.12.6. 9.13. 10.8.5.2

10-28
December 1989

A.1 1.6 File selection

D

1 R

PROFILES

1 R

F-SELECT POU m m m m

RANGE OF VALUES

rIcLD NAME OR REFERENCE

State result m m ail values defined in lau oo/i

Action result m m all values defined in li>0 857

1

Attributes m m m m see A.10.2, 9.17.9

Requested access m m see A.12.16

Access passwords o m see 9.16 2. 10.8.8

Concurrency control 0 m see A.12.13. 10.8 6.1

Shared ASE information 0 0 i 1 see 9.5(8)

Account 0 o see 9.18.4, 10.8.8

Diagnostic 0 m see A.12.6, 9.13

A. 11. 7 File deselection

D

1 R

PROFILES

1 R

F-DESELECT PDU m m m m

RANGE OF VALUES

FIELDNAME OR REFERENCE

Action result m m all values defined in ISO 8571

Chargir>g 0 - o see A.12.10

Shared ASE information 0 0 1 1 see 9.5(8)

Diagnostic 0 • m see A.12.6. 9.13

10-29
December 1989

A.1 1.8 File creation

n

1 R

rrHJrlUCo

1 R

1 F-CREATE PDU c c c c see A.11. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 State result m - m all values defined in ISO 857

Action result - m • m all values defined in ISO 8571

Override m - m see A.12.15

Initial attributes m m m m see A.10.2. 9.10.2.2. 9.17.9

Create password 0 m see A.12.12. 9.16.2, 10.8.7 10 8.8

Requested access m tn - see A.12.16

Access passwords 0 m - see 9.16.2. 10.8.8

Concurrency control 0 m see A.12.13. 10.8.6.1

10 Shared ASE information 0 0 i 1 see 9.5(8)

11 Account 0 o - see 9.18.4, 10.8.8

12 Diagnostic 0 m see A. 12.6, 9.13

A.1 1.9 File deletion

D

1 R

PRORLES

1 R

1 F-DELETE PDU c c c c see A ll, A.12.5

FIELDNAME

RANGE OF VALUES

OR REFERENCE

2 Action result - m • m all values defined in ISO 857

3 Shared ASE information 0 0 i 1

4 Charging - 0 - o see A.12.10

S Diagnostic - 0 • m see A.12.6. 9.13

10-30
December 1989

A.1 1.10 Read attributes

D

1 R

PRORLES

1 R

1 F-READ-ATTRIB PDU c c c c see A.11. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result - m - m all values defined in ISO 8571

3 Attribute names m m

4 Attributes - 0 m see A.10.2. 9.17.9

S Diagnostic - 0 • m see A12.6. 9.13

A.1 1 .1 1 Change attributes

D

1 R

T1.3, T2.3, A1.3 M1.3

1 R

1 F-CHANGE-ATTRIB c c 1 m m see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result - m 1 - m all values defined in ISO 8571

3 Attributes fn 0 i m m see A.10.2. 9.17 9

4 Diagnostic - 0 i - m see A.12 6, 9.13

A. 11. 12 File open

D

1 R

T1.3, T2.3, A1.3

1 R

M1.3

F-OPEN PDU c c m m 1 see A.11, A.12.5

FIELDNAME

RANGE OF VALUES

OR REFERENCE

State result - m m all values defined in ISO 8571

Action result m • m all values defined in ISO 8571

Processing mode m - m - see A.12.17

Contents type m m m m see A. 12.7.2

Concurrency control 0 0 m o se« A.12.13. 10.8.6.1

Shared ASE information 0 0 1 1 see 9.5(3)

10-31
December 1989

• EnaWe FADU locking m - m • 1 falseforTl.aandTa.a

9 Activity identifief 0 - o

10 Diagnostic - 0 m 1 see A. 12.6. 9.13

11 Recovery mode m m m m 1 see A. 12.18

12 Remove contexts 0 -

1 .

13 Define contexts 0 -

1 -

14 Presentation action m m 1 see notes

NOTES

1 The values available for the presentation action field depend upon the fur>ctional units implemented in ISO 8823.

2 Presentation action field is indicated as mandatory in accordance with ISO 8571-4. The field is defaulted to no action.

A.11.13 File Close

D T1.3, T2.3, A1.3 M1.3

1 F-CLOSE PDU c m i see A ll. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result m m 1 all values defined in ISO 8571

3 Shared ASE information 0 1 1 see 9.5(8)

4 Diagnostic 0 m 1 see A.12.6. 9.13

A. 11. 14 Beginning of grouping

D

1 R PROFILES1 R

1 F-BEGIN-GROUP PDU c c c c see A ll. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Threshold m - m

A.11.15 End of grouping

D PROFILES

F-END-GROUP PDU c c see A ll. A. 12.5

The F-ENO-GROUP PDU carries no fields. 10-32
A.11.16 Regime recovery

December 1989

D T1.3, T2.3, A1.3 Ml.

3

1 R i R

1 F-RECOVER PDU c c c c i see A.11. A.12 5 RANGE OF VALUES

FIELD NAME OR REFERENCE

2 State result - m - m I all values defined in ISO 8571

3 Action result - m - m 1 aJI values defined in ISO 8571

4 Activity identifier m - m - 1

S Bulk transfer number m - m - i see 10.9

e Requested access m - m - 1 see A.I 2. 16

7 Access passwords 0 - m • 1 see 9.16.2, 10.8.8

a Contents type - m - m 1 see A.12.7.2

9 Recovery point m m m m 1

10 Diagnostic - 0 - m 1 see A.12 6. 9.13, 10.8.5.2

11 Remove contexts 0

-

1 • 1 see notes

12 Define contexts 0 -

1 • 1 see notes

13 Presentation action - m m I see notes

NOTES

1 The values available for the presentation action field depend upon the functional units implemented in ISO 8823.

2 Presentation action field is indicated as mandatory in accordance with ISO 8571-4. The field is defaulted to no action.

A.11. 17 Locate file access data unit

D T1.3, T2.3

1 R

A1.3

1 R

Ml.

3

1 F-LOCATE PDU c c 1 m m 1 see A ll. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Action result - m 1 - m 1 all values defined in ISO 8571

3 FADU idenbt>' m 0 1 m o 1 see 9.17.9

4 FADU lock 0 - 1 o - 1 see A.12.14

5 Diagnostic - 0 1 - m 1 see A.12.6, 9.13

10-33
December 1989

A.11.18 Erase file access data unit

D T1.3, T2.3 A1.3 M1.3

I R I R

F-ERASE PDU c c 1 m m 1 see A.11. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result - m 1 - m 1 all values defined in ISO 8571

FADU identity m - 1 m • 1 see 9.17.9

Diagnostic - 0 1 • m i see A.12.6. 9.13

A. 11. 19 Read bulk data

D

1 R

T1.3, T2.3

1 R

A1.3

t R

M1.3

F-READ PDU c c c c m m 1 see A.11, A.12.5

FIELDNAME

RANGE OF VALUES

OR REFERENCE

FADU idenbty m m - m 1 see 9.17.9

Access context m m m 1 see A. 10.3.2.3

FADU lock 0 1 0 1

A.1 1.20 Write bulk data

D

1 R

T1.3, T2.3

1 R

A1.3

1 R

M1.3

F-WRITE PDU c c c c m m see A ll, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

FADU operation m - m • m - 1

FADU identity m - m - m - 1 see 9.17.9

FADU Lock 0 -

1 o 1

10-34
December 1989

A.1 1 .21 End of data transfer

D T1.3, T2.3, A1.3 Ml.

3

F-DATA-END PDU c m 1 see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m m 1 all values defined in ISO 8571

Diagnostic 0 m 1 see A.12.6, 9.13

A.1 1,22 End of transfer

1 DR

T1.3, T2.3, A1.3 Ml.

3

1 R

F-TRANSFER-END PDU c c m m 1 see A ll. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m - m 1 all values defined in ISO 8571

Shared ASE information 0 0 i 1 i see 9.5{8)

Diagnostic 0 - m 1 see A.12.6, 9.13

A.1 1 .23 Cancel data transfer

See section 9.11 D T1.3, T2.3, A1.3 Ml.

3

F-CANCEL PDU c m i see A.11, A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

Action result m m 1 all values defined in ISO 8571

Shared ASE information 0 i i see 9.5(8)

Diagnostic 0 m i see A.12.6. 9.13

A.1 1 .23.1 F-CANCEL mapping

See sections 9.11, 9.17.10

10-35
December 1989

A.1 1 .24 Restart data transfer

D T1.3, T2.3, A1.3 Ml.

3

1 F-RESTARTPDU c c S see A ll. A.12.5

FIELD NAME

RANGE OF VALUES

OR REFERENCE

2 Checkpoint tdentifier m m 1

A.1 2 Expanded PDU field and filestore detail

This clause identifies further PDU field and filestore detail to expand on that given in A. 10 and A.11.

A.1 2.1 Implementation information detail

See sections 9.5(6), 9.12, 10.8.3

A.1 2.2 Access control detail

See sections 9.9.2, 10.7.3 Access control element terms D PROFILES

RANGE OF VALUES

1 Action list m m

2 Concurrency access o o see A. 12 3,3

3 Identity o o

4 Passwords o o see A 12 3 5, A.12 3 6. 10.8 8

5 Location o o

A.1 2.3 Access control element detail

A.1 2.3.1 Action list detail (InKlator)

( Void

)

A.1 2.3.2 Action list detail (responder)

{ Void

)

10-36
December 1989

A.1 2.3.3 Concurrency access term

If the concurrency access term is supported in the access control element the following details of the concurrency

control shall be available with each action.

T1 T Action

not required

D T1.3

shared

D T1.3

exclusive

D T1J

no access D T1.3

1 Read 0 0 0 o 0 o o o

2 Insert 0 1 0 1 0 1 o 1

3 Replace 0 0 0 o 0 o o o

4 Extend 0 0 0 o 0 o 0 o

5 Erase 0 1 0 1 0 1 0 i

6 Read attributes 0 0 0 o 0 o o o

7 Change attributes 0 1 0 1 0 1 0 1

a Delete file 0 0 0 o 0 o 0 o

T2.3 Action

not required

D T2.3

shared

D T2.3

exclusive

D T2.3 no access D T2.3

9 Read 0 0 0 o 0 0 o o

10 Insert 0 0 0 o 0 o 0 o

11 Replace 0 0 0 o 0 o 0 o

12 Extend 0 o 0 o 0 o 0 0

13 Erase 0 1 0 i 0 i 0 1

14 Read attributes 0 o 0 o 0 o 0 o

IS Change attributes 0 1 0 1 0 1 0 1

16 Delete file 0 0 0 o 0 o 0 o

10-37
December 1989

A1.3

Action

not required

D A1.3

shsrsd

D A1.3

exclusive

D A1.3 no access D A1.3

17 Read 0 0 0 o 0 o 0 o

18 Insert 0 0 0 o 0 o 0 o

19 Replace 0 o 0 o o o 0 o

20 Extend 0 o 0 o 0 o 0 o

21 Erase 0 0 0 o 0 o 0 o

22 Read attributes 0 Q o o 0 o 0 o

23 Change attributes 0 1 0 1 0 1 0 1

24 Delete file o o 0 o o o 0 o

Ml.3 not required

Action D M1.3

shared

D M1.3

exclusive

D

no access

M1.3 D Ml.

3

25 Read 0 0 1 0 0

26 Insert 0 0 I o 0

27 Replace 0 0 0 0

2B Extend 0 0 0 o

29 Erase 0 0 0 0

30 Read attributes 0 0 0 o 0 o 0 o

31 Change attributes 0 0 0 o 0 o o o

32 Delete file 0 0 0 o o o c o

A.1 2.3.4 Identity term

( Void )

A.1 2.3.5 Initiator access passwords

If the passwords term of the access control element is implemented the foltowing values shall be supported for the

initiator role. See section 9.16.3

Initiator Access Passwords D PROFILES

1

1 OctetString 0 o

2 GraphicString 0 o

10-38
December 1989

A.1 2.3.6 Responder access passwords

If the passwords term of the access control element is implemented the following values shall be supported for the responder role. See section 9.16.3 Responder Access

Passwords

D T1.3 OctetStrIng

GraphlcStrlng

T2.3 OctetStrIng

GraphlcStrlng

A1.3

OctetStrIng

GraphlcStrlng

Ml.

3

OctetStrIng

GraphlcStrlng

Read-passwofd 0 o o o 1

Insert-password 0 1 o 0 1

Replace-password 0 o o 0 1

Ertend-password 0 o o 0 1

Erase-password 0 1 I 0 i

Read-attribute-password 0 o o 0 o

Change-anribcite-password 0 i i 1 o

Delete-password 0 0 o 0 o

A.I 2.3.7 Location term

( Void

)

A.1 2.3.7.1 Application Entity Titles detail

See section 9.5(7)

A.12.3.8 Access control element combinations

Combinations D PROFILES

R

Identity Password Location 0 0

Identity Password 0 0

Identity Location 0 o

Password Location 0 o

Identity 0 o

Password 0 0

Location 0 0

NOTE - Implementation of access control without any of the above combinations is valid.

10-39
December 1989

A.12.4 Service class field detail

Se« table 9.7 and sections 10.5.1, 10.8.1 D T1.3, T2.3 A1.3 Ml.3(T) Ml.3 (A)

Transfer dass 0 m 1 m 1

Access dass o 1 m 1 m

Management dass oil m m

Transfer and management dass 0 o 1 m 1

Unconstrained dass u I i 1

NOTES

1 The initiator is only permitled to specify those oomt>inations defined in ISO 8571-3

2 The notation M1.3(T) Indicates M1.3 combined with a Transfer Profile T1.3 or T2.3. M1.3<A} means M1.3 combined with the Access Profile A1.3.

A.12.5 Functional unit field detail

See table 9.7 and sections 10.8,1, 10.8.2

11.3, T2.3

FUNCTIONAL UNITS

SERVICE CLASSES

Transfer Transfer and Management

D T1.3, T2.3 D T1.3, T2.3

1 Kernel m m m m

2 Read (see note 2) CO CO

i Write (see note 2) CO CO 4 File Access

i Limited File Management 0 o mm 6 Enhanced

File Management 0 1 0 i

7 Grouping mm mm S FAOU Locking

9 Recovery 0 O 0 o

10 Restart 0 O CO

NOTES

1 the recovery and the restart functional units are only available at the interna! file service interface and should only be explicitly referenced in the protocol. 2 the c indicates that either or both of the read and write functional units shall be implemented in the particular service class.

10-40
December 1989

A1.3

FUNCTIONAL UNITS

SERVICE CLASSES

Access

D A1.3

11 Keme) m m

12 Read m m

13 Write m m

14 File Access m m

IS Limited RIe Management 0 o

^

Flic li?.T\3o^. c I

17 Grouping 0 o

18 FADU Locking 0 o see 10.8.6.2

19 Recovery 0 o

20 Restart 0 o

See 10.8.1

M1.3(T) SERVICE CLASSES

Transfer Management Transfer and Management

FUNCTIONAL UNITS D M1.3(T) D M1.3(T) D M1.3(T)

21 Kernel m m m m

22 Read c o

23 Write c 0

24 nie Access

25 Limited RIe Management 0 m mm m m

26 Enhanced

File Management 0 m 0 m o m

27 Grouping m m m m

28 FADU Locking

2S Recovery 0 o

30 Restart 0 o

NOTE - M1.3(T) indicates Ml .3 in conjunction with a Transfer Profile T1.3 or T2.3. This taWe fists only the addtionsl furvctionalitv- as

defined by Ml.3.

10-41
December 1989

Ml.3(A)

FUNCTIONAL UNITS

S«« 10.8.1 SERVICE CLASSES

Acxiess

D Ml.3(A)

Management

D Ml.3(A)

Kernel

3S

37

39

Read

Write

File Access

Limited Rle Management

Enhanced

File Management m

Grouping

FADU Locking

Recovery

Restart

NOTE - M1.3{A) indicates Ml 3 in conjunction with the Access Profile A1.3. This table lists only the additional functionality as defined by M1.3.

A.12.6 Diagnostic field detail

D T1.3, T2.3, A1.3 M1.3

Diagnostic type m m m

Error identifier m m m

Error observer m m m

Error source m m m

Suggested delay o c 1 see 10.8.5.2

Further details 0 m m

For values of the 'further details' term only the support of character strings of th« ISO 646, IRV (GO) and ISO 8859-1 (GO and G1) character sets Is required (see sec. y.l3j.

10-42
A.12.7 Contents type detail December 1989

A.I 2.7.1 Contents type list parameter

See section 9.10.2,1

D PROFILES

1 R

Maximum number of elements

document type specifications

abstract syntax specifications

0

0

o m

o m

A.I 2.7.2 Contents type parameter

See section 9.10.2.3 D PROFILES REFERENCE

document type specifications 0 m see 9.9.1

abstract syntax / constraint set pair

specifications

0 1

NOTE - The detail of document types supported is contained in dause A. 13.

A.12.8 FTAM Quality of service details

See section 10.8.5.2

A.I 2.9 Details of shared ASE Information

( Void

)

A.I 2.10 Details of charging

See section 9.5(8), 9.18.4

Charging D PROFILES

R

Resource identifier term m m

Charging unit term m m

Charging value term m m

10-43
December 1989

A.I 2.1 1 Filestore password detail

Filestore password detail D PROFILES

OctetString o o

GraphicString 0 o

A.I 2.1 2 Create password detail

See section 9.16.3

Create password detail D PROFILES

OctetString o o

GraphicString 0 o

A.12.13 Concurrency control

A.12.13.1 Supported values

See section 10.8.6.1

T1.3

not required shared exclusive no access

Action D T1.3 D T1.3 0 T1.3 D T1.3

Read 0 o 0 o 0 o 0 o

Insert 0 1 0 1 0 1 o 1

Replace 0 o 0 o o o 0 o

Extend 0 o 0 o 0 0 o o

Erase 0 1 0 1 0 1 o 1

Read attrib 0 o 0 o 0 o 0 o

Change attrib 0 i 0 1 0 1 0 I

Delete file 0 o 0 o 0 o 0 o

10-44
December 1989

T2.3

not required shared exclusive no access

Action D T2.3 D T2.3 D T2.3 D T2.3

« Read 0 0 0 o 0 o 0 o

10 Insert 0 o o o 0 o o o

11 Replace 0 o 0 o o o 0 o

12 Extend 0 o 0 o 0 o 0 o

13 Erase 0 1 o 1 0 1 0 1

14 Read attrib 0 o o o 0 o 0 o

25 Change attrib 0 i 0 1 0 1 0 1

16 Delete file 0 0 0 o 0 o 0 o

A1.3

not required shared exclusive no access

Action D A1.3 D A1.3 D A1.3 D A1.3

17 Read 0 o 0 o 0 o o 0

18 Insert 0 0 0 o 0 0 0 o

IS Replace 0 o 0 o 0 o 0 o

20 Extend 0 0 0 o 0 o 0 o

21 Erase 0 0 0 o 0 o 0 o

22 Read attrib 0 0 0 o 0 o 0 o

23 Change attrib 0 I 0 1 0 1 0 1

24 Delete file 0 o 0 o 0 0 0 o

10-45
December 1989

M1.3

not required shared exclusive no access

Action D M1.3 D M1.3 D M1.3 D M1.3

25 Read 0 0 o o 1

26 Insert 0 o o 0 1

27 Replace 0 o • 0 o 1

2S Extend 0 o o o i

29 Erase o 0 0 o 1

30 Read attrib 0 o 0 o 0 o 0 o

31 Change attrib 0 o 0 o 0 o 0 o

32 Delete file 0 o o o 0 o 0 o

A.12.13.2 Responder Default values

See sections 9.14, 10.8.6.1

A.12.14 FADU Locking

A1.3

not required

FADU Locking Support Values

shared exclusive no access

D A1.3 D A1.3 D A1.3 D A1.3

Read 0 o 0 o 0 o 0 o

Insert 0 o 0 o 0 o 0 o

Replace 0 o 0 0 0 o 0 o

Extend 0 o o o 0 o 0 o

Erase 0 o o o 0 o 0 o

10-46
December 1989

A.1 2.1 5 Initiator Override

Initiator override D PROFILES

1

1 Create failure o o

2 Select old file o o

3 Delete and recreate with old attributes o o

4 Delete and create with new attributes o o

NOTE - The specification of the role of resporxJer is given in the filestore section

A.I 2.1 6 Requested Access

See section 9.15

Action D T1.3 T2.3 A1.3 M1.3

Read o o o o

Insert o 1 o o

Replace o 0 o o ,

Extend o 0 o 0

Erase o X X 0

Read attribute o 0 o 0 m

Change attribute o 1 1 1 m

Delete file o o o 0 m

A.12.17 Processing mode

Processing mode D T1.3 T2.3 A1.3 M1.3

Read o o o o

Insert o 1 o o

Replace o o o o

Extend o o o o

Erase o X X o

10-47
December 1989

A.12.18 Recovery mode

See section 10.8.5.2

Recovery mode D T1.3, T2.3, A1.3 M1.3

None o m 1

At start of transfer 0 m 1

Any active cfieckpoint 0 o i

10-48
March '90

Section 6 : Document Type Detail

A.13 Document types

See section 10.7.1

Conformance to document types is given at two levels. The following table indicates which document types have some level of support. The detail of that level of support is stated in the following tables.

Entry number FTAM-1 D 11 .3 T2.3 A1.3 Ml.

3

Object descriptor ISO FTAM unstructured text o m m m i

Object identifier {iso standard 8571 document-type(5) unstructured-text(l)} see A. 13.1

Entry number FTAM-2 D 11 .3 T2.3 A1.3 Ml.

3

Object descriptor

Object identifier

ISO FTAM sequential text o

{iso standard 8571 document-type(5) sequential-text(2)}

i m m i

see A. 13.2

Entry number FTAM-3 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor

Object identifier

ISO FTAM unstructured binary o

{iso standard 8571 document-type(5) unstructured-binary(3)} m m m i see A. 13.3

Entry number FTAM-4 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor ISO FTAM sequential binary o i o o i

Object identifier {iso standard 8571 document-type(5) sequential-binary(4)} see A. 13.4

Entry number NBS-6 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-6 FTAM sequential file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) sequential(6)

}

see A. 13.5

Entry number NBS-7 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-7 FTAM random access file i o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

docunnent-type(5) random-file(7)

}

see A. 13.6

10 - 49
March '90

Entry number NBS-8 D T1.3 T2.3 A1.3 M1.3

Object descriptor NBS-8 FTAM indexed file i o o j

Object identifier {iso identified-organization oiw{14) ftamsig(5)

document-type(5) indexed-file(8)

}

see A. 13.7

Entry number NBS-9 D T1.3 T2.3 A1.3 Ml.

3

Object descriptor NBS-9 FTAM file directory file o o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) file-directory(9)

}

see 9.18.3

Entry number NBS-10 D T1.3 T2.3 A1.3 Ml.

3

9 Object descriptor NBS-10 FTAM random binary access file j o o i

Object identifier {iso identified-organization oiw(14) ftamsig(5)

document-type(5) random-binary(IO) } see 10.7.1

j Entry number NBS-11 D T1.3 T2.3 A1.3 M1.3

Object descriptor

Object identifier

NBS-1 1 FTAM indexed file with unique keys

{iso identified-organization oiw(14) ftamsig(5)

document-type(5) indexed-file-with-unique-keys(ll)

}

i o o i

see A. 13.8

Entry number NBS-1

2

D T1.3 T2.3 A1.3 IVII.S

Object descriptor

Object identifier

NBS-1 2 NBS FTAM simple text file

{iso identified-organization oiw(14) ftamsig(5)

document-type(5) simple-text-file(12) }

i o o i

see A. 13.9

10 - 50
December 1989

Constraint sets and FADU Identities for document types

For the constraint set / FADU identity tables the following notation is used:

mandatory

optionai not supported

not applicable excluded

In the constraint set definition, or optional in the constraint set definition but shall be implemented by implementations

claiming conformance to the Profile. The support of the FADU identity will be dependent on the actions which have been

implemented.

in the constraint set definition (outside the scope of this ISP, may be ignored)

(not defined in ttie constraint set definition) (disallowed in the document type definition or in FTAM Phase 3)

Implementation Profile T1.3.

^^^^^^^ FADU Identity

Constraint Set ^'^'^x^,^^

Begin End First Last Current Next Previous Node

Seq

Node

Number

FTAM unstructured

constraint set m

FTAM-1 m

FTAM-3 m

NBS-9 m

10-51
December 1989

Implementation Profile T2.3 (see sees. 9.10, 10.7.2)

^^^^ FADU Wenlity

Constraint S€t ^^^^

Begin End First Last Current Next Previous Node

Seq

Node

Number

FTAM unstructured

constraint set m

FTAM -

1

m

FTAM - 3 m

NBS-9 m

FTAM sequential flat constraint set o o o o o o 0 o

FTAM-2 m m i 1 1 1 1 1

FTAM-4 m m 1 1 1 1 1 1

NBS-6 m m 1 X X 1 X X

NBS-12 m m X X X X X X

FTAM ordered flat constraint set 0 o 0 0 o o o 0 o

NBS-6 m 1 1 1 1 i 1 m 1

FTAM ordered flat constraint set with unique names

o o o o o o o

NBS-11 m 1 1 1 1 m I

NBS ordered flat constraint set o o 0 o o o o 0

NBS-7 m m m m 1 1 1 m

NBS random access

constraint set o o o 0

NBS-10 m m m m

10-52
December 1989

Implementation Profile A1.3 (see section 9.10)

^^v^ FADU Identity

Constraint Set

Begin End First Last Current Next Previous Node

Soq

Node

Number

FTAM unstructured

constraint set m

FTAM-1 m

FTAM-3 m

NBS-9 m

FTAM sequential flat constraint set o o o o o o o o

FTAM-2 m m m i i m 1 1

FTAM-4 m m m 1 i m 1 1

NBS-6 m m m X X m X X

NBS-12 m m m X X m X X

FTAM ordered flat constraint set o o o o o o o o o

NBS-8 m m 1 1 m m m m 1

FTAM ordered flat constraint

set with unique names

o o 0 o o o o

NBS-11 m m m m m m 1

NBS ordered flat constraint set o o 0 c o 0 o o

NBS-7 m m m m m m m m

NBS random access

constraint set o o o 0

NBS-10 m m m m

10-53
December 1989

A.I 3.1 FTAM-1 (See section 10.7.1)

A.I 3.1.1 Universal class number parameter (See section 9.10.1)

B T1.3, T2.3, A1.3

Universal dass number parameter supported 0 m

PrintableString - Universal dass 19 0 1

TeletexStrir>g Universal dass 20 0 1

VideotexString - Universal dass 21 0 1

lASString Universal dass 22 0 m see 9.10.1.1-2

GraphicString Universal dass 25 0 m see A.13.1.3

VisibleString Universal dass 26 0 m

GeneralString Universal dass 27 0 m see A.13.1.4

A. 13.1.2 String length parameter and string significance parameter combinations

D T1.3, T2.3, A1.3

Maximum string length parameter and

variable length strings

0 m

Maximum string length parameter and

fixed length strings

0 m

Maximum string length parameter and

not significant strings

0 m

Unbounded strings and

variable length strings

o m

Unbounded strings and

not significant strings

0 m

A.13.1.3 G sets supported

G sets which are supported in FTAM-1 GraphicString.

For values of GraphicString only the support of character strings of the ISO 646, IRV (GO) and ISO 8859-1 (GO and Gl)

character sets is required,

(see 9.10.1.1, 9.10.1.3)

10-54
A.13.1.4 G and C Mts supported

G and C sets which are supported in FTAM-1 GeneralString

December 1989

1 For value* of GeneralString only the support of diaracter strlnge of the ISO 646, IRV (GO) and ISO 88S9-1 (GO and G1)

character sets and ISO 646 IRV (CO) control character set Is required

(see 9.10.1-3)

A.13.2 FTAM-2 (see section 10.7.1)

A.13.2.1 Universal class number parameter (see section 9.10.1)

D T2.3, A1.3

Universal dass number parameter supported 0 m

PrintableString - Universal class 19 0 1

TeletexString Universal class 20 0 1

VideotexString - Universal class 21 0 1

lASString Universal class 22 0 o see 9.10.1.1-2

GraphicString Universal class 25 0 m see A. 13. 2.

3

VisibleString Universal class 26 0 m

GeneralString Universal class 27 0 o see A. 13. 2.

4

A.I 3.2.2 String length parameter and string significance parameter combinations

D T2.3, A1.3

1 Maximum string ler^gth parameter and

variable length strings

0 1

2 Maximum string length parameter and

fixed length strings

0 1

3 Maximum string length parameter and

not significant strings

0 m

4 Unbounded strings and

variable length strings

0 1

S Unbounded strings and

not significant strings

0 m

10-55
A.I 3.2.3 G sets supported

G sets which are supported in FTAM-2 GraphicString.

December 1989

For values of GraphicString only the support of character strings of the ISO 646, IRV (GO) and (SO 8859-1 (GO and Gl)

character sets Is r&qulred.

(see 9.10.1.1. 9.10.1.3)

A.I 3.2.4 G and C sets supported

G and C sets which are supported in FrAM-2 GeneralString

For values of GeneralString only the support of character strings of the ISO 646, IRV (GO) and ISO 8859-1 (GO and Gl)

character sets and ISO 646 IRV (CO) control character set Is required,

(see 9.10.1.1-3)

A.13.3 FTAM-3

A.13.3.1 String length parameter and string significance parameter combinations (see section 10.7.1)

D T1.3, T2.3, A1.3

Maximum string length parameter and

variable length strings

0 1

Maximum string length parameter and

fixed length strings

0 1

Maximum string length parameter and

not significant strings

0 m

UnbourKied strings and

variable length strings

o 1

Unbounded strings and

not significant strings

0 m

10-56
A.13.4 FTAM-4 (see section 10.7.1) December 1989

A.I 3.4.1 String tength parameter and string significance parameter combinations

D T2.3, A1.3

Maximum string length parameter and

variable length strings

0 1

Maximum string length parameter and

fixed length strings

0 1

Maximum string length parameter and

not significant strings

0 m

Unbounded strings and

variable lenorh strings

o 1

Unbounded strings and

not significant strings

0 m

10-57
A.13.5 NBS-6

A.I 3.5.1 ParameterO

See tables 9.2, 9.3

December 1989

D T2.3, A1.3

ParameterO supported m

Universal-time Universal class 23 m

Generalized-time Universal class 24 - m

boolean Universal dass 1 m

null Universal dass 5 m

., ..

A.13.5.2 Parameterl (see section 9.10.1)

n TO AIT

Parameterl supported in

integer Universal dass 2 m

bit Universal dass 3 m

IA5 Universal class 22 m

GraphicString Universal class 25 m

GeneralString Universal class 27 m

OctetString Universal dass 4 m

A.1 3.5.3 Parameter2

D T2.3, A1.3

Parameter2 supported o

10-58
A.13.6 NBS-7

A.I 3.6.1 ParameterO

Sm tables 9.2, 9.3

December 1989

D T2.3, A1.3

ParameterO supported m

Universal-time Universal dass 23 - m

Generalized-time Universal dass 24 - m

boolean Universal dass 1 - m

null Universal dass 5 - m

A.I 3.6.2 Parameterl (see section 9.10.1)

D T2.3, A1.3

Parameterl supported m

integer Universal dass 2 - m

bit Universal dass 3 m

IA5 Universal dass 22 m

GraphicString Universal dass 25 - m

GeneralString Universal dass 27 - m

OctetString Universal dass 4 m

A.I 3.6.3 Parameter2

D T2.3, A1.3

1 Parameter2 supported o

10-59
A.I 3.7 NBS-8 December 1989

S«e tables 9.2, 9.3

n*lw*fal A 1 7 1 PflrAmetfirO r Oi oil ioi V

Data Types

D T2.3, A1.3

Key Type

D T2 3 A1 3

ParameterO supported m m

Universal-time Universal dass 23 m m

Generalized-time Universal dass 24 m m

boolean Universal dass 1 m

null Universal dass 5 m

(see section 9.10.1)

Data Types

D T2.3, A1.3

Key Type

U 1 A 1 .0

Parameterl supported m m

integer Universal dass 2 m m

D(t Universal dass 3 m

Universal dass 22 m m

Universal dass 25 m in

GeneralString Universal dass 27 m m

OctetString Universal dass 4 m m

A.1 3.7.3 Parameter2

Data Types Key Type

D T2.3, A1.3 D T2.3, A1.3

Parameter2 supported o o

10 - 60
A.13.8 NBS-11

A.1 3.8.1 ParameterO

See tabids 9.2, 9.3

December 1989

Data Types

D T2.3, A1.3 Key Type

D T2.3, A1.3

ParameterO supported m m

Universal-time Universal class 23 m m

Generalized-time Universal class 24 m m

boolean Universal dass 1 m

null Universal dass 5 m

A.I 3.8.2 Parameterl (see section 9.10.1)

Data Types

D T2.3, A1.3 Key TypeD T2.3, A1.3

Parameterl supported m m

integer Universal dass 2 m m

bit Universal dass 3 m

IA5 Universal class 22 m m

GraphicString Universal class 25 m m

GeneralString Universal class 27 m m

OctetString Universal dass 4 m m

A.I 3.8.3 Parameter2

Data Types

D T2.3, A1.3

Key Type

D T2.3, A1.3

Parameter2 supported o 0

10 - 61
December 1989

A.13.9 NBS-12 (see sectlom 0.7.1)

A.13.9.1 Universal class number parameter (see section 9.10.1)

D T2.3, A1.3

1 Untversal dass number parameter supported m

2 PrintaWeString - Universal class 19 - 1

TeletexString - Universal class 20 - 1

VideotexString - Universal class 21 - 1

lASString - Universal class 22 m

GraphicString - Universal dass 25 m see A. 13.9.5

VisibleString - Universal class 26 m

GeneralString - Universal class 27 m see A. 13.9.6

A.1 3.9.2 String length parameter

D T2.3, A1.3

Maximum string length parameter supported m

A.1 3.9.3 String significance parameter

D T2.3, A1.3

1 Siring significance parameter supported m

2 Variable length strings supported m

3 Fixed length strings supported m

A.1 3.9.4 Character set parameter

D T2.3, A1.3

1 Character set parameter supported m

10-62
December '89

A.1 3.9.5 G sets supported

G sets which are supported in NBS-12 GraphicString.

1 For values of GraphicString only the support of character strings of the ISO 646, IRV (GO) and ISO 8859-1 (GO and G1)

character sets is required,

(see 9.10.1.1, 9.10.1.3)

A.1 3.9.6 G and C sets supported

G and C sets which are supported in NBS-12 GeneralString.

1 For values of GeneralString only the support of character strings of the ISO 646, IRV (GO) and ISO 8859-1 (GO and Gl)

character set and ISO 646 IRV (CO) control character sets is required,

(see 9.10.1.1-3)

- END OF FTAM PHASE 3 PROFILES REQUIREMENTS LIST -

) 10 - 63
March '90

I APPENDIX B : NIST OIW REGISTER OF FTAM OBJECTS

B.1 Introduction

This index, the NIST OIW Register of OIW FTAM objects, contains a complete list of all FTAM objects as defined

by NIST OIW.

NIST OIW was authorized by BSI in its letter dated August 09, 1989, as Registration Authority for NIST OIW defined

objects. The Object Identifier Prefix for OIW is

{ iso(1) identified-organization{3) oiw(14)

}

NIST OIW Plenary has delegated the authority and the task for maintenance of the NIST OIW Register of FTAM

objects to its FTAM Special Interest Group (SIG) at its meeting on September 15, 1989. The Object Identifier Prefix

for the FTAM SIG is

{ iso(1) identified-organization(3) oiw(14) ftamsig(5)

}

For the FTAM Phase 2 dof i nod objects, the FTAM S I G has decided to koop tho ad hoc Object I denti fier val ues as desi g

n ated i n 1987 and 1988 with the not necessaril y un i que Object I dentif ie r Pref i x

{ i60(1) i d e nt i fi ed-'Organ i zat i on(3) i cd( 9 999) organ i zat i on - codQ(1 )

}

Th e r eason is that FTAM Phase 2 products we r e already complet ed and r ele ased to u se rs , so that changing these val ues woul d resu l t i n seri ous i ntorworki ng probl ems.

For each new OIW FTAM object to be registered, a complete technical definition, that describes the purpose, scope

and the unique characteristics of the object, must be prepared and presented to OIW FTAM SIG for technical discussion and acceptance, and for final approval by OIW Plenary.

10 - 64
March '90

INDEX of QIW FTAM Objprts

B.2.1 FTAM Phase 2 Defined Qbjorts

I Object Identifier Prefix : nist-adhoc := iso(1) identified-organization(3) icd(9999) organization-code(l)

Object Object Descriptor Object Identifier Date of Registration

Reference to Definition

NBS-6 NBS-6 FTAM

sequential file {nist-adhoc

document-type(5)

sequentiai(6)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-1 77

chapter 9, appendix A.I

NBS-7 NBS-7 FTAM random

access file {nist-adhoc

document-type(5)

random-file(7)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

chapter 9, appendix A.2

NBS-8 NBS-8 FTAM

indexed file {nist-adhoc

document-type(5)

indexed-filG(8)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-1 77

chapter 9, appendix A.

3

NBS-9 NBS-9 FTAM file directory file {nist-adhoc

document-type(5)

file-directory(9)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

chapter 9, appendix A.4

NBS ordered flat constraint set {nist-adhoc

constraint-set(4)

nbs-ordered-f[at(1)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

chapter 9, appendix B.I

kino A O -4 NBS-AS

1

NBS abstract syntax AS1{nist-adhoc

abstract-syntax(2)

nbs-asl(l)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NIST SP 500-177

chapter 9, appendix C.I

NBS-AS2 NBS file directory

entry abstract syntax

{nist-adhoc

abstract-syntax(2)

nbs-as2(2)

}

Dec 15, '89 Withdrawn

March 16, '90

Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

chapter 9, appendix C.2

AP-Title {nist-adhoc

ftam-nil-ap-title(7)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1, Dec '89 NISTSP 500-1 77

section 5.12.1.1.1

10 - 65
March '90

Object Identifier Prefix : nist-oiw-ftam := iso(1) identified-organization(3) oiw(14) ftamsig(5)

Object Object Descriptor Object Identifier Date of

rit?y loll allUl 1 Reference to

tJxSl II IIIIUI

1

NBS-6 NBS-6 FTAM

sequential file {nist-oiw-ftam

document-type(5)

sequential(6)

}

March 1 6, '90 Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-1 77

NBS-7 NBS-7 FTAM random

access file

{nist-oiw-ftam

document-type(5)

random-file(7)

}

March 16, '90 Stable Agreements

Vers. 3. Ed. 2, March '90 NIST SP 500-177

NBS-8 NBS-8 FTAM

indexed file {nist-oiw-ftam

document-type(5)

indexed-file(8)

}

March 16, '90 Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

NBS-9 NBS-9 FTAM file directory file {nist-oiw-ftam

document-type(5)

file-directory(9)

}

March 16, '90 Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

L/iicl|JLc;l ctlJiJcilUIA r\.0

NBS ordered flat constraint set

{nist-oiw-ftam

constraint-set(4)

nbs-ordered-flat(1 )

}

March 16, '90 Stable Agreements

Vers. 3, Ed. 2, March '90 NISTSP 500-177

chapter 9, appendix B.2

NBS-AS1 NBS abstract syntax AS1

{nist-oiw-ftam

abstract-syntax (2) nbs-as1(1)

}

March 1 6, '90 Stable Agreements

Vers. 3, Ed. 2, March '90 NIST SP 500-177

chapter 9, appendix C.3

NBS-AS2 NBS file directory

entry abstract syntax

{nist-oiw-ftam

abstract-syntax (2) nbs-as2(2)

}

March 16, '90 Stable Agreements

Vers. 3, Ed. 2. March '90 NIST SP 500-177

chapter 9, appendix C.4

10-65-1

March '90

B.2.2 FTAM Phase 3 Defined Objects

j Object identifier Prefix : nist-oiw-ftam := iso(1) identified-organ!2ation(3) oiw(14) ftamsig(5)

Object Object Descriptor Object Identifier Date of Registration

Reference to Definition

NBS-10 NBS-10 random

binary access file

{nist-oiw-ftam

document-type(5)

random-binary(IO)

}

Dec 15, "89 Stable Agreements

Vers. 3, Ed. 1, Dec '89 NISTSP 500-177

chapter 10, appendix C.I

NBS-11 NBS-11 FTAM Indexed

file with unique keys

{nist-oiw-ftam

document-type(5)

indexed-file-with-uniquel<eys(11)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1 . Dec '89 NIST SP 500-177

chapter 1 0, appendix C.2

NBS-12 NBS-12 FTAM

simple text file {nist-oiw-ftam

document-type(5)

simple-text-file(12)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1 , Dec '89 NISTSP 500-177

NBS Random Access {nist-oiw-ftam

constraint-set(4)

nbs-random-access(2)

}

Dec 1 5, '89 Stable Agreements

Vers. 3, Ed. 1 , Dec '89 NISTSP 500-177

Ltldpic^l 1 U, appollUiA 1

NBS-AS3 NBS random access node name abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-node-name(3)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1, Dec '89 NISTSP 500-1 77

chapter 10, appendix E.I

NBS-AS4 NBS random binary access file abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-random-binary(4)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1 , Dec '89 NIST SP 500-177

chapter 10, appendix E.2

NBS-AS5 NBS simple text abstract syntax

{nist-oiw-ftam

abstract-syntax(2)

nbs-simple-text(5)

}

Dec 15, '89 Stable Agreements

Vers. 3, Ed. 1. Dec '89 NIST SP 500-177

chapter 10, appendix E.3

10 - 66
March 1990 (Stable)

1:0.-1:2 APPENDIX C: DOCUMENT TYPES

C . 1 NBS-10 Random Binary Access Document Type

1. Entry Number: NBS-10

2. Information objects

Table 10.2. Information objects in NBS-10

document type name

!

{iso identified-organization

oiw(14) ftamsig(5) documenttype(5) rando'^-birjary ( 10) ) "NBS-10 random binary access file"

abstract syntax names:

a) name of asnamel

b) name of asname2

c) name of asname3

{iso identified-organization

oiw(14) rtamsig(D; abstract- syntax(Z)

nbs- random-binary (4)

)

"NBS random binary access file abstract

syntax"

{iso standard 8571 abstract- syntax( 2) ftamfadu(2)}

"FTAM FADU"

{iso identified-organization

oiw(14) ftamsig(5) abstract- syntax(2)

nbs-node-name(3)

}

"NBS random access node name abstract

syntax"

transfer syntax names: { joint-iso-ccitt asnl(l) basic-encoding(l)

}

"Basic encoding of a single ASN.l type"

file model {iso standard 8571 file-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso identified-organization

oiw(14) ftamsig(5) constraint-set (4)

nbs-random-access (2) ) "NBS random access constraint set"

File contents:

Datatypel : := a single octet

Datatype2 : := Node -Name

--The type to be used for Node-Name is defined in

--ISO 8571-FADU

--The only Choice for Node-Name is user-coded

Datatypes : := NBS -Node-Name

--As defined by the NBS Node Name Abstract Syntax

10-67
March 1990 (Stable)

3. Scope and field of application

This document type defines the contents of a file for storage, for

transfer and access by FTAM.

4 . References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management

5 . Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6 . Abbreviations

FTAM File Transfer, Access and Management

7. Document semantics

The document consists of zero, one or more file access data units

each of which consists of one data element. The data element is made

up of one octet. The order of these elements is significant. The

semantics of the data elements is not specified by this document type.

The document structure takes the form allowed by the FTAM

hierarchical file model as constrained by the NBS random access constraint set. The definition for FTAM hierarchical file model

appears in 8571-2.

There are no size or length limitations imposed by this definition.

8. Abstract syntactic structure

The abstract syntactic structure of the document is a series of

octets

.

9. Definition of transfer

9.1. Datatype definition

The presentation data value used for transfer is an ASN.l OCTET

STRING

.

Datatype2 is used to specify the FADU- Identity of "name-list" in

th3 FTAM PDUs specifying FADU-Identity, where "name-list" is

defined as a SEQUENCE of EXTERNAL. The EXTERNAL is defined as Node-Name in the FTAM FADU abstract syntax. The use of Datatype2

is defined in "NBS random access constraint set."

10-68
December '89

Datatypes specifies the "user-coded" form of the Node-Name in the

FTAM FADU abstract syntax, where "user-coded" is defined as an

EXTERNAL. That EXTERNAL is defined by Datatypes. The use of

Datatypes is defined in "NBS random access constraint set."

9 . 2 Presentation data values

The document is transmitted as a series of presentation data

values. Each presentation data value shall consist of the "data"

from one or more FADUs concatenated together. The result is one value of the ASN.l data type OCTET STRING. The "fadu_count"

field supplied in the Node-Name specifies the number of FADUs to

transfer during a Read operation. The requested FADUs may be

transferred as one or more presentation data values.

All values are transmitted in the same (but any) presentation

context established to support the abstract syntax name "asnamel"

declared in table 10.2.

Note: Specific carrier standards may impose additional

constraints on the presentation context to be

used, when the above permits a choice.

Boundaries between P-DATA primitives and between presentation

data values are chosen locally by the sending entity at the time

of transmission. The boundaries are not preserved when the file

is stored and they carry no semantics of the document type.

Receivers which support this document type shall accept a document with any of the permitted transfer options.

9 . 3 Sequence of presentation data values

The sequence of presentation data values is the same as the

sequence of Data Units within the file.

10. Transfer syntax

An implementation supporting these document types shall support

the transfer syntax generation rules named in table 10.2 for all

presentation data values transferred.

Implementations may optionally support other transfer syntaxes.

11. ASE specific specifications

11.1 Simplification and relaxation

The document type NBS- 10 may be simplified to the document type

FTAM-3. The resultant document contains the same sequence of

data values as would result from accessing the file as an NBS- 10

file.

10-69
December '89

11.2 The READ operation

A READ operation may be applied to a range of FADUs via the FADU

Identity of "NodeSeq." The "starting-fadu" part of the node

name specifies the node number of the first FADU; the "faducount" specifies the number of consecutive FADUs to be

transferred.

A READ operation applied to a range of FADUs that spans beyond

the end of file is valid. All available data in the range is

transferred. An informative diagnostic (5005) is returned on the

F-Data-End Request indicating that the end of file was reached

and a portion of the request was satisfied.

11.3 The REPLACE operation

When the REPLACE operation is applied to the root FADU of an NBS10 document, the transferred data shall be any NBS-10 document.

The REPLACE operation applied to a FADU identity of "node

number" is used to replace a series of FADUs, starting at the

specified position in the file, by the new FADUs being

transferred. The number of replaced FADUs is determined by the

number of transferred FADUs.

If the replacement spans beyond the end of the existing file,

then the additional FADUs are inserted at the end of the file.

11.4 The INSERT operation

When the INSERT operation is applied at the end of file, the

transferred data shall be a series of FADUs which would be

generated by reading any NBS-10 document type in access context

UA.

10-70
March 1990 (Stable)

C.

2

NBS-11 Indexed Sequential File With Unique Keys

1. Entry Number: NBS-11

2. Information objects

Table 10.3. Information objects in NBS-11

document type name {iso identified-organization

oiw(14) ftamsig(5) document- type (5)

indexed-file-with-unique-keys (11)

)

"NBS-11 FTAM indexed file with unique keys"

abstract S3mtax names:

a) name for asnamel

b) name for asname2

{iso identified-organization oiw(14)

ftarasig(5) organization-eode(-t)

abstract S3mtax(2) nbs-asl(l))

"NBS abstract syntax ASl"

{iso standard 8571 abstract-syntax(2) ftamfadu(2)

}

"FTAM FADU"

transfer syntax names: { joint-iso-ccitt asnl(l) basic-encoding(l)

) "Basic Encoding of a single ASN.l type"

parameter syntax:

PARAMETERS : := SEQUENCE {DataTypes, KeyType, KeyPosition)

DataTypes : := SEQUENCE OF CHOICE {ParameterO, Parameterl , Parameter2)

KeyType : := CHOICE {ParameterO, Parameterl, Parameter2)

ParameterO, Parameterl, Parameter2, as defined for the

-- document types NBS-6, NBS-7, NBS-8

KeyPosition: := INTEGER

file model {iso standard 8571 file-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set (4)

ordered- flat-unique-names (4)

}

"FTAM ordered flat constraint set with

unique names"

file contents:

Datatypel : := PrimTjrpe -- as defined in Appendix 9C, C.3

Annex -9 -A ,- -Part -3 of NIST SP 500-t62 177

Datatype2 : := CHOICE { Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element ) Exic-Suocree-Data-Element }

10-71
March 1990 (Stable)

3. Scope and field of application

The document type defines the contents of a file for storage, for

transfer and access using FTAM.

Note: Storage refers to apparent storage within the Virtual

Filestore.

4. References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management

5. Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6 . Abbreviations

FTAM File Transfer, Access and Management

7. Document semantics

The document consists of zero, one or more file access data units,

each of which consists of zero, one or more data elements. The order

of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the FTAM ordered flat

constraint set with unique names (see table 10.3). These definitions

appear in ISO 8571-2.

The following additional requirements are specified for the use of

the ordered flat constraint set with unique names:

o The FADU identity 'node number' is not required for

conformant implementations

o The identities 'next' and 'previous' are allowed for all

FADUs

Each data element is a data type from the set of primitive data types

defined in Appendix -9A,- -Part -S -of -NIST -5GG-t&2 Appendix 9C, C.3 of

NIST SP 500-177. Each data unit contains the same data element types

in the same order as all other data units. These types and their

respective maximum lengths are defined by the <DataTypes> parameter.

10-72
December '89

NBS-11 Indexed Sequential File With Unique Keys

1. Entry Number: NBS-11

2. Information objects

Table 10.3. Information objects in NBS-11

document type name {iso identif ied-organization

oiw(14) ftamsig(5) document- type (5)

indexed- file -wi th-unique - keys (11)}

"NBS-11 FTAM indexed file with unique keys"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization icd(9999)

organization-code(l) abstractsyntax(2) nbs-asl(l))

"NBS abstract syntax ASl"

{iso standard 8571 abstract-syntax(2) ftamfadu(2)

)

"FTAM FADU"

transfer syntax names: ( joint-iso-ccitt asnl(l) basic-encoding( 1

)

} "Basic Encoding of a single ASN.l type"

parameter syntax:

PARAMETERS : := SEQUENCE {DataTypes, KeyType, KeyPosition}

DataTypes : := SEQUENCE OF CHOICE {ParameterO, Parameter 1 , Parameter2}

KeyType : := CHOICE {ParameterO, Parameterl , Parameter2}

ParameterO, Parameterl, Parameter2, as defined for the

-- document types NBS-6, NBS-7, NBS-8

KeyPosition: := INTEGER

file model {iso standard 8571 f ile-model(3)

hierarchical ( 1 )

)

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set(4)

ordered-flat-unique-naraes(4)

}

"FTAM ordered flat constraint set with

unique names"

file contents:

Datatypel : := PrimType -- as defined in Annex 9 A, Part 3 of NIST SP 500-162

Datatype2 ::= CHOICE { Node-Descriptor-Data-Element,

Enter-Subtree-Data-Element } Exit-Subtree-Data-Element )

10-71
December '89

3. Scope and field of application

The document type defines the contents of a file for storage, for

transfer and access using FTAM.

Note: Storage refers to apparent storage within the Virtual

Filestore.

4 . References

ISO 8571, Information Processing Systems - Open Systems

Interconnection -File Transfer, Access and Management

5 . Definitions

This definition makes use of the terms data element, data unit and

file access data unit as defined in ISO 8571-1.

6 . Abbreviations

FTAM File Transfer, Access and Management

7. Document semantics

The docximent consists of zero, one or more file access data units,

each of which consists of zero, one or more data elements. The order

of each of these elements is significant.

The document structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the FTAM ordered flat

constraint set with unique names (see table 10.3). These definitions

appear in ISO 8571-2.

The following additional requirements are specified for the use of

the ordered flat constraint set with unique names:

o The FADU identity 'node number' is not required for

conformant implementations

o The identities 'next' and 'previous' are allowed for all

FADUs

Each data element is a data type from the set of primitive data types

defined in Appendix 9A, Part 3 of NIST 500-162. Each data unit

contains the same data element types in the same order as all other

data units. These types and their respective maximum lengths are defined by the <DataTypes> parameter.

10-72
March 1990 (Stable)

The string- length field of Parameter 1 specifies the length of the

value in octets for the INTEGER, BIT STRING and OCTET STRING types.

For character- type data elements, the string-length indicates the

actual number of characters from the specified character set, not

including any escape sequences or overhead from the character

encoding

.

For floating point numbers, finite form, length-1 and length-2 specify

the length in bits of mantissa and exponent, respectively. The

length-1 and length-2 values are irrelevant for the other choices of

floating point numbers.

Each data unit in the file has a key associated with it, which is the

user-coded form of Node Name. The key of each data unit is of the same data type as the key of all other data units in the file and is a single data element from the set of primitive data types defined in

I Appendix -9A,- -Part -S -of -NIST-5GG-1:62t Appendix 9 C, C.3 of NIST SP

I 500-177.

The type and length of the key are defined by the <KeyType>

parameter

.

The primitive data types and minimum size ranges of each unit which

an implementation must accept as a key value are given in the

following table 10.4.

Table 10.4. Datatypes for keys

Kev Tvpe Minimum Range (octets) Order

ASN.l INTEGER (1-2) increasing numeric value

ASN.l lASString (1-16) lexical order

ASN.l GraphicString (1-16) lexical order

ASN.l GeneralString (1-16) lexical order

ASN.l OCTET STRING (1-16) increasing value

ASN.l GeneralizedTime increasing time value

ASN.l UniversalTime increasing time value

NBS-ASl FloatingPointNumber increasing numeric value

The position of the key in the data unit is specified by the

<KeyPosition> parameter.

KeyPosition = 0 implies the key is not part of the data

KeyPosition > 0 specifies the actual data element in the data unit.

8. Abstract syntactic structure

10-73
March 1990 (Stable)

The abstract syntactic structure of the document is a hierarchically

structured file as defined in the ASN.l module IS08571-FADU in ISO

8571, in which each of the file access data units has the abstract

syntactic structure of NBS-ASl as defined by the parameters.

Definition of transfer

1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 10.3, where the PrimType in the

datatjrpe is given by the NBS-ASl definition; or

b) Datatype2 defined in table 10.3, which is the ASN.l datatype

declared as "Data-Element" in the ASN.l module IS08571-FADU.

2 Presentation data values

The document is transferred as a series of presentation data

values, each of which is either

a) one value of the ASN.l datatype "Datatypel," carrying one of the data elements from the document. All values are transmitted in the same (but any) presentation context

defined to support the abstract syntax name "asnamel" or

b) a value of "Datatype2." All values are transmitted in the same (but any) presentation context defined to support the

abstract syntax name "asname2."

Notes: 1. Specific carrier standards may impose additional

constraints on the presentation context to be

used, where the above permits a choice

2. Any document type defined in this entry either

makes no use of Datatype2 , or starts with a Datatype2 transmission.

Boundaries between presentation data values in the same presentation context, and boundaries between P-DATA primitives,

are chosen locally by the sending entity at the time of

transmission, and carry no semantics of the document type.

Receivers which support this document type shall accept a document with any of the permitted transfer options (e.g.,

document type parameters and transfer syntaxes)

.

3 Sequence of presentation data values

10-74
December '89

The sequence of presentation data values of type a) and the

sequence of presentation data values of types a) and b) is the same as the sequence of data elements within a Data Unit, and

Data Units in the hierarchical structure, when flattened

according to the definition of the hierarchical file model in

ISO 8571-2.

10. Transfer syntax

An implementation supporting this document type shall support

the transfer syntax generation rules named in table 10.2 for all

presentation data values transferred. Implementation may

optionally support other named transfer sjmtaxes.

11. ASE specific specifications for FTAM

11.1 Simplification and relaxation

11.1.1 Structural simplification

This simplification loses information.

The document type NBS-11 may be accessed as a document type

FTAM- 3 (allowed only when reading the file) by specifying

document type FTAM- 3 in the <contents type> parameter in <FOPEN request>, and limiting access context to UA on F-READ.

The octet representation of the transferred data is

unpredictable. It will usually correspond to the data values as stored in the local Real Filestore of the Responder.

A document of type NBS-11 can be accessed as a document of type

NBS-6 (allowed only when reading the file) by specifying

document type NBS-6 with appropriate data type parameters in the

<contents type> parameter on the <F-OPEN request>. The

traversal order of the FADUs must be maintained.

Note: The traversal order is as reading the file as NBS-11 in

key order.

A document of type NBS-11 may be accessed as a document of type

NBS-8 (allowed only when reading the file) by specifying

document type NBS-8 in the <contents type> parameter in the <FOPEN REQUEST>.

11.2 Access context selection

A document of type NBS-11 may be accessed in any one of the access contexts defined in the FTAM ordered flat constraint set

10-75
December '89

with unique names. The presentation data units transferred in

each case are those derived from the structuring elements defined

for that access context in ISO 8571-2,

11.3 The INSERT operation

When the <INSERT> operation is applied the transferred material

shall be the series of FADU which would be generated by reading

any NBS-11 document with the same parameter values in access context FA.

A transferred FADU whose name duplicates that of an already

existing FADU will cause the <INSERT> operation to fail. The

failure shall be signalled by issuing an F-CANCEL Request with a corresponding diagnostic.

11.4 The EXTEND operation

This operation is excluded for the use with this document type.

11.5 The REPLACE operation

When the <REPLACE> operation is applied with FADU Identity

'begin' , a transferred FADU whose name duplicates that of a previously transferred FADU will cause the <REFLACE> operation

to fail. The failure shall be signalled by issuing an F-CANCEL

Request with a corresponding diagnostic.

10-76
March 1990 (Stable)

I C. 3 NBS-12 Simple Text File Document Type

1. Entry Number: NBS-12

2. Information objects

Table 10.5. Information objects in NBS-12

document type name {iso identified-organization

oiw(14) ftamsig(5) documenttype(5) simple-text-file(12)

}

"NBS-12 FTAM simple text file"

abstract syntax names:

a) name for asnamel

b) name for asname2

{iso identified-organization

oiw(14) ftamsig(5) abstract-syntax(2)

nbs-simple-text(5)

)

"NBS simple text abstract syntax"

{iso standard 8571 abstract-syntax(2) ftamfadu(2)

)

"FTAM FADU"

transfer sjmtax names: { joint-iso-ccitt asnl (1) basic-encoding (1))

"Basic Encoding of a single ASN.l type"

Parameter Syntax

PARAMETERS : := SEQUENCE

{

universal -class -number [0] IMPLICIT INTEGER,

maximum- string- length [1] IMPLICIT INTEGER,

string-significance [2] IMPLICIT INTEGER {variable (0), fixed (1)},

character-set [3] IMPLICIT OctetString OPTIONAL)

file model {iso standard 8571 file-model(3)

hierarchical(l)

)

"FTAM hierarchical file model"

constraint set {iso standard 8571 constraint-set (4)

sequential flat(2)}

"FTAM sequential flat constraint set"

File contents

Datatype 1 : := NBS Text

--as defined in the NBS Simple Text

--Abstract Syntax registration entry

Datatype2 : := Node-Descriptor-Data-Element

3. Scope and field of application

The document type defines the contents of a file for storage, and for

transfer and access by FTAM.

10-77
March 1990 (Stable)

4. References ^

ISO 8571, Information Processing Systems - Open Systems Interconnection - File Transfer, Access and Management

ISO 8824, Information Processing Systems-Open Systems InterconnectionSpecification of Abstract Syntax Notation 1 (ASN.l).

ISO 8825, Information Processing Systems-Open Systems InterconnectionBasic Encoding Rules for Abstract Syntax Notation One (ASN.l).

ISO 6429, Information Processing-ISO 7-bit and 8-bit coded character setsAdditional control functions for character imaging devices.

5. Definitions

This definition makes use of the terms data element, data unit and file access data unit as defined in ISO 8571-1. In addition, it makes use of the

terms character string, graphics character, and format effector as defined

in document type registration entry "FTAM-2" ir ISO 8571-2.

6 . Abbreviations

FTAM File Transfer, Access and Management

7 . Document semantics ^ This document consists of zero, one or more file access data units, each of

which consists of one character string. The order of each of these elements

is significant. The semantics of the character strings is not specified by

this document type.

The docviment structure takes any of the forms allowed by the FTAM

hierarchical file model as constrained by the sequential flat constraint

set. These definitions appear in ISO 8571-2. As additional constraints

FADU identity will be limited to the following values:

a) 'begin' and 'end' when using the Transfer or Transfer and

Management service classes.

b) 'begin', 'end', 'first', and 'next' when using the Access service

class

.

Each character string consists of characters from the character set defined

by the ASN.l (ISO 8824) character set type whose universal class number is

given by the "universal-class-number" parameter and by the escape sequences

contained in the optional "character-set" parameter. If the character set

type allows explicit escape sequences, the "character-set" parameter, if

present, contains escape sequences which designate and invoke specific

(

10-78
December '89

character sets. If the "character-set" parameter is not present, character

sets are assumed to be designated and invoked as specified in table 2 in ISO

8825. Character strings shall not contain escape sequences.

There are no size or length limitations imposed by this definition, except

those specified here. Each character string is of a length determined by

the number of characters given by the "maximum- string- length" parameter.

Note: The length restriction refers to the number of characters

from the applicable character set, not to the number of

octets in the encoding, nor to the line length in any

rendition of the document, where these are different.

The exact significance of the character strings is determined by the

" string- s ignificance " parameter. If its value is "variable," the length of

the character strings is less than or equal to the length given. If the

value is "fixed," the length of each character string is exactly equal to

the length given.

If the document is interpreted on a character imaging device (outside the

scope of ISO 8571), the interpretation depends on the character set in use.

a) If the character set contains format effectors, they shall be

interpreted as defined in ISO 6429; end of string and end of file access data unit are given no formatting significance, and do not

contribute to the document semantics;

b) If the character set does not contain format effectors, the end of

each character string is interpreted as implying carriage return

and line feed formatting actions in any rendition. The end of

file access data unit is given no formatting significance beyond

that attached to the end of the string in it.

8. Abstract syntactic structure

The abstract syntactic structure of the document is a hierarchically

structured file as defined in the ASN.l modules IS08571-FADU and ISO 8571-

CONTENTS in ISO 8571, in which each of the file contents data elements has

the abstract syntactic structure of "NBS Simple Text."

9. Definition of transfer

9.1 Datatype definitions

The file consists of data values which are of either

a) Datatypel defined in table 10.5, the ASN.l datatype declared as "NBS -Text" in the NBS Simple Text Abstract Syntax definition. The

choice in "NBS-Text" is determined by the universal-class-number

parameter; or 10-79
December ' 89

b) Datatype2 defined in table 10.5, the ASN.l datatype declared as "Data-Element" in the ASN.l module ISO 8571-FADU.

9.2 Presentation data values

The document is transferred as a series of presentation data values

,

each of which is either

a) one value of the ASN.l datatype "Datatypel , " carrying one of the

character strings of the document. Each character shall be

transmitted using one of the character sets identified by the

universal -class -number parameter. All values are transmitted in

' the same (but any) presentation context established to support the

abstract syntax name "asnamel" declared in table 10.5, or

b) one value of the ASN.l datatype "Datatype2." All values are transmitted in the same (but any) presentation context

established to support the abstract syntax name "asname2"

declared in table 10.5.

Notes: 1. Specific carrier standards may impose additional

constraints on the presentation context to be used,

where the above permits a choice.

2. Any document type defined in this entry either

makes no use of Datatype2, or starts with a Datatype2 transmission.

, Boundaries between P-DATA primitives are chosen locally by the sending

entity at the time of transmission, and carry no semantics of the

document type. Receivers which support this document type shall accept

a document with any of the permitted transfer options.

9 . 3 Sequence of presentation data values

The sequence of presentation data values of type (a) and the sequence

of presentation data values of types (a) and (b) is the same as the

sequence of character strings within a Data Unit, and Data Units in the

hierarchical structure, when flattened according to the definition of

the hierarchical file model in ISO 8571-2.

10. Transfer syntax

An implementation supporting this document type shall support the

transfer syntax generation rules named in table 10.5 for all

presentation data values transferred.

11. ASE specific specifications

11.1 Simplification and relaxation

11.1.1 Simplification to FTAM-1

10-80
December '89

This simplification loses information.

The document type NBS-12 may be accessed as a document type FTAM1 . The resultant document contains the same sequence of data

values as would result from accessing the structured text file in access context UA. That is, only the presentation data values in

the abstract syntax "asnamel" are present. If the "character-set"

parameter was present before the simplification, its contents will

be added to the beginning of each string.

Note: The boundary between file access data units remains

a boundary between strings, but any special

significance given to it is lost.

11.1.2 Relaxation to FTAM-2

The document type NBS-12 may be relaxed to the document type FTAM2. If the "character-set" parameter was present before the

relaxation, its contents will be added to the beginning of each

string

.

11.1.3 Character set relaxation

This operation loses explicit information in the document type

identification.

A document of type NBS-12 may be relaxed to a different document

of type NBS-12 with

o a different "universal-class-number" parameter value,

o a different "character-set" parameter value,

o different values for both of these parameters,

o a different "universal-class-number" parameter value and no "character-set" parameter value, or

o no "character-set" parameter value,

if the resultant document type permits all characters from the

original document type. If this relaxation involves including

format effectors and none were present before the simplification,

the characters "carriage return" and "line-feed" shall be added to

the end of each string.

Note: If the characters "carriage return" and "line feed" are not part of the format effectors, the

formatting action may be represented by "newline,"

or some other implementation specific choice if

there is no representation of "newline" defined.

11.1.4 String length relaxation

10-81
December ' 89

This operation loses explicit information in the document type

identification.

A document of type NBS-12 may be relaxed to another document type

NBS-12 with a larger "maximum- string- length" parameter.

11.2 Access context selection

A document of type NBS-12 may be accessed in any one of the access contexts defined in the sequential flat constraint set. The

presentation data units transferred in each case are those derived from

the structuring elements defined for that access context in ISO 8571-2.

11.3 The INSERT operation

When the INSERT operation is applied at the end of file, the

transferred material shall be the series of FADUs which would be

generated by reading any NBS-12 document type with the same parameter

values in access context FA.

10-82
March 1990 (Stable)

10.-1:3 APPENDIX D: CONSTRAINT SETS

D.l NBS Random Access Constraint Set

Table 10.6. Basic constraints in the NBS Random Access Constraint Set

Constraint set descriptor NBS Random Access

Constraint set identifier {iso identified-organization

oiw(14) ftamsig(5) constraint-set(4)

nbs-random-access (2)

}

Node names All names shall be of the same type; the

type of the names and an ordering of the names shall be defined when reference is

made to the constraint set.

File access actions Locate, Read, Insert, Erase, Replace

Qualified actions None

Available access context UA

Creation state Root node without an associate data unit

Location after open Root node

Beginning of file Root node

End of file No node selected

Read whole file Read in access context UA with FADUIdentity of'begin"

Write whole file Transfer a series of leaf FADUs which

would be generated by reading the whole

file in access context UA; Perform the

transfer with an FADU Identity of "end"

and a file access action of "insert," or with an FADU Identity of "begin" and an action of "replace," or with an FADU

Identity of "node-number" and an action of "replace." Here "node

number" identifies the first FADU in the

preorder traversal sequence.

10-83
March 1990 (Stable)

Table 10.7. Identity constraints in the NBS Random Access Constraint Set

Action Begin End NodeSeq Node Number

Locate leaf

Read whole leaf

Insert leaf

Erase whole leaf

Replace whole leaf

Note: NodeSeq = A sequence of node names with a single member

1 . Field of application

The NBS Random Access constraint set applies to files which are structured

into a sequence of individual FADUs and to which access may be made randomly

by NodeSeq. The structuring of the file into individual FADUs is determined

by the NodeName

.

2 . Basle constraints

The basic constraints in the NBS Random Access constraint set are given in

table 10.6.

3 . Structural constraints

The root node shall not have an associated data unit; all children of the

root node shall be leaf nodes and shall have an associated data unit; all arcs from the root node shall be of length one.

4. Action constraints

Insert: the insert action is allowed only at the end of the file, with

FADU-Identity of "end"; the new node is inserted following all existing

nodes in the file. The location following the insert is "end."

Erase: the erase action is allowed at the root node to empty the file, with

FADU-Identity of "begin." The result is a solitary root node without an associated data unit. Erase with the FADU-Identity of "node number" means truncation of the file.

Replace whole file: the FADU-Identity is "begin" and the complete series of

new FADU contents is sent.

Replace new leaves: the FADU-Identity is "node number" and the number of

FADUs being replaced is given by the number of FADUs sent.

5 . Identity constraints

The FADU-Identity associated with the file action shall be one of the

identities: begin, end. Node Number and NodeSeq. The actions with which ^

10-84
March 1990 (Stable)

these identities can be used are given in table 10.7.

10-85
March 1990 (Stable)

to .-14 APPENDIX E: ABSTRACT SYNTAXES

E.l NBS Node Name Abstract Syntax

Abstract Syntax Name

{ iso identified-organlzation oiw(14) ftamsig(5) abstract- syntax( 2)

nbs-node-name(3) )

"NBS random access node name abstract syntax"

This is an abstract syntax for the user-coded Node-Name in the FTAM

FADU abstract syntax.

( starting- fadu [0] IMPLICIT INTEGER,

fadu- count [1] IMPLICIT INTEGER } --a "fadu-count" of 0 specifies the

--range of FADUs

--beginning at "starting- fadu" and

--ending at "end of file"

For this abstract syntax the following transfer syntax will be used,

{ joint-iso-ccitt asnl(l) basic-encoding(l) ) "Basic Encoding of a single ASN.l type"

E.2 NBS Random Binary Access File Abstract Syntax

Abstract Syntax Name

{ iso identified-organization oiw(14) ftamsig(5) abstract- syntaxC 2)

nbs-random-binary(4) }

"NBS random binary access file abstract syntax"

This is an abstract syntax for the transfer of the file contents for

NBS Random binary files.

NBS-AS3 DEFINITIONS: :=

BEGIN

NBS-Node-Name: := SEQUENCE

END

NBS-AS4 DEFINITIONS: :=

BEGIN

NBS -Random Binary : := OCTET STRING

--contains one or more presentation data values

--concatenated together.

--Each presentation data value is defined as

10-86
March 1990 (Stable)

--Datatypel in table 10.2.

END

For this abstract syntax the following transfer syntax will be used.

{ j oint- iso-ccitt asnl(l) basic-encoding(l) } "Basic Encoding of a single ASN.l type"

I E.3 NBS Simple Text Abstract Syntax

Abstract Syntax Name

{iso identified-organization oiw(14) ftamsig(5)

abstract- syntax( 2) nbs- simple- text (5) ) "NBS simple text abstract syntax"

NBS-AS5 DEFINITIONS : :=

BEGIN

NBS -Text: := CHOICE {

IA5String ,- -Universal Class 22

GraphicString ,- -Universal Class 25

VisibleString ,- -Universal Class 26

GeneralString- -Universal Class 27

) END

For this abstract syntax, the following transfer syntax will be used:

{ j oint- iso-ccitt asnl(l) basic-encoding( 1 )

)

"Basic encoding of a single ASN.l type"

10-87

December '89

11 DIRECTORY SERVICES PROTOCOLS

11.1 INTRODUCTION

This is an Implementation Agreement developed by the Implementor's Workshop sponsored

by the National Institute of Standards and Technology to promote the useful exchange of

data between devices manufcictured by different vendors. This agreement is bcised on euid employs protocols developed in accord with the OSI Reference Model. While this agreement

introduces no new protocols, it eliminates ambiguities in interpretations.

This is an Implementation Agreement for the OSI Directory based on the ISO and

CCITT documents cited in the Reference section 19.2 (hereafter referenced as Directory

Documents). This agreement is aligned with the UNOFFICIAL 'FINAL' version of the

X.500 Series of Recommendations, December 1988. Where technicaJ differences between

the ISO and CCITT versions of these documents exist (e.g., Transport Requirements) the

ISO versions are given precedence, figure 11.1 displays the structure of this Implementation

Agreement. References to corresponding CCITT documents are included for information.

Directory Access Protocol

(DAP)

Directory System Protocol

(DSP)

Remote Operations Services and Protocols

(CCITT X.219 and X.229/ISO 9072/1 and 9072/2)

Association Control Services and Protocols

(CCITT X.217 and X.227/ISO 8649 and 8650)

Figure 11.1. Structure of this Implementation Agreement.

The Directory User Agents (DUAs) and Directory System Agents (DSAs) provide access

to The Directory on behalf of humans and applications such as Message Handling and File Transfer, Access, and Management. See the Scope and Field of Application section for more

information on the model used in the Directory.

This document covers both the Directory Access Protocol (DAP) and the Directory

System Protocol(DSP) defined in the Directory Documents. A good working knowledge of

the Directory Documents is assumed by this chapter. All terminology and abbreviations

used but not defined in this text may be found in those documents.

11.2 SCOPE AND FIELD OF APPLICATION

Centralized and distributed directories can both be accorrunodated in this Agreement by the

appropriate choice of protocols and pragmatic constraints from those specified. Figure 11.2

illustrates a centralized directory and figure 11.3 illustrates a distributed directory.

11 - 1
December '89

This agreement does not cover interaction between co-located entities, such as a co- resident DUA and DSA. It also does not specify the interface between a user (person or

application) and a DUA. Bilateral agreements between a DUA and DSA or DSA and DSA

may be implemented in addition to the requirements stated in this document. Conformance

to this agreement requires the ability to interact without the use of bilateral agreements

other than those required in the Directory Documents.

The logical structure of the Directory Information Base (DIB) is described in the Directory Documents. The manner in which a local portion of the DIB is organized and accessed

by its DSA is not in the scope of this agreement.

11.3 STATUS

This version was completed in December 1989.

11.4 USE OF THE DIRECTORY

Given the rapid multiplication and expansion of OSI applications, telecommunication sys- tems and services, there is growing need for users of OSI applications, as well as the applications themselves, to communicate with each other. In order to facilitate their communications, a Directory protocol, as referenced in these agreements, has been tailored to meet

their respective needs.

In one instance. The Directory will be used as a service to provide humans, in an on-line

fashion, rapid and easy retrieval of information useful for determining what telecommunications services are available, and/or how to access, and address their correspondents. Further,

service providers offering such a Public Directory may also use this service internally with

other various telecommunications services (e.g., MHS) for the proper addressing of calls or messages. Likewise, this does not preclude the usage of these agreements to similarly generate a privately operated Directory that supports both human and application information

exchanges.

In another instance. The Directory, will be used as a service by computer applications

without direct human involvement. One important service is to provide Presentation Address resolution for named objects, on behalf of OSI applications. The Directory may be

used by apphcations to search for objects (i.e., Apphcation Entities), without direct human

involvement, by the use of the "search" or "list" operations.

To support the many possible usages, The Directory is a general purpose system. It

is capable of storing data of many different forms as attributes within entries, and is also capable of supporting simple or complex hierarchical structures, with variations in structure

possibly occurring between one part of The Directory and another.

Compliant DSA implementations should safeguard this generality, where possible, by

placing the minimum of restrictions in "hard-wired" form.

11-2
December '89

fa The Directory

USER

USER

DUA

DUA

DSA

Figure 11.2. Centralized Directory Model.

User

DUA

User DUA The Directory

DSA

DSA DSA

User DUA DSA DUA User

Figure 11.3. Distributed Directory Model.

11-3
December '89

11.5 DIRECTORY ASEs AND APPLICATION CONTEXTS

This section highlights the ASEs (Application Service Elements) and Application Contexts

defined in the Directory Documents and of concern in these Agreements. The functionality

of the Directory AEs (DUAs and DSAs) is defined by a set of ASEs, each Directory ASE

specifying a set of Directory operations.

The interaction between these AEs is described in terms of their use of ASEs. This

specific combination of a set of ASEs and the rules for their usage defines an application

context. The following ASEs are described in the Directory Documents:

• Read ASE

• Chained Read ASE ,

• Search ASE

• Chained Search ASE

• Modify ASE

• Chained Modify ASE

ROSE and ACSE also form part of the Directory Application Contexts.

The following Application Contexts are described in the Directory Document:

• Directory Access AppHcation Context

• Directory System Application Context

11.6 SCHEMA

There are seven (7) major topics that relate to schema:

11.6.1 Support of Structures and Naming Rules

DSAs shall be capable of supporting (subject to refinements laid down in these Agreements)

the structure and naming rules defined in the Directory Documents, Part 7, Annex B.

Part 7, Annex B of the Directory Documents provides a framework for the basic use of

the Directory in terms of the objects defined in Part 7. It does not, however, form part of

the standard and, in any case, permits structures and practices which may be undesirable.

The guidelines below provide tighter control within the Annex B framework.

It is recommended that only an entry subordinate to Root or Country may use a State- OrProvinceName AVA as an RDN.

11-4
I December '89

11.6.2 Support of Object Classes and Subclasses

The DSAs shall be able to support all superclasses of the supported object classes (e.g., Top, Person).

Use of an object class in this profile or the standard (or a subclass derived from one or more of these object classes) is recommended wherever the semantics are appropriate for the

application. The derivation of a new object class as an immediate subclass of Top should

be avoided. For example, to represent printers in the Directory, one can derive a subclass

of Device.

An entry of a particular object class may contain any optional attribute Hsted for it in the Directory Documents; a conformant DSA shall be able to support all these optional

attributes.

In addition, a DSA may permit any locally registered attribute, or a subset of these,

by providing the local extension facilities permitted by unregistered object classes (viz.

Directory Documents, Part 2, clause 9.4.1 (a) and Note).

11.6.3 Support of Attribute Types

DSAs shall be able to support the storage and use of attribute type information, as defined

in the Directory Documents, Part 6, including their use in naming and access to entries; they shall also support the definition of new attribute types, making use of pre-existing

attribute syntaxes.

DSAs shall support the encoding, decoding, and matching of all the attributes in the

Naming Prefixes of every naming context they hold (ref Directory Documents, Part 4, clause

9). These attributes may include attributes that are not permitted to appear in entries in those naming contexts.

11.6.4 Support of Attribute Syntaxes

Suggested methods for the interpretation of selected Attribute Syntaxes are defined in Appendix A.

11.6.5 Naming Contexts

The root of a naming context shall not be an alias entry.

11.6.6 Common Profiles

This section identifies profiles that are commonly useful for various applications while an

appUcation-specific profile(s) is identified by the application.

11-5
December '89

11.6.6.1 OIW Directory Common Application Directory Profile

11.6.6.1.1 Standard Application Specific Attributes and Attribute Sets

The attributes and attribute sets in the Directory Document, Part 6, associated with the

object classes Usted below are required.

11.6.6.1.2 Standard Application Specific Object Classes

DSAs shall be able to support storage and use of the object classes below, as defined in the

Directory Documents, Part 7, and these object classes are expected to be useful for a range

of applications.

The following object classes are mandated by the standard:

Top Alias

DSA

The following object classes are expected to be generally useful in the creation of the upper

portion of the DIT:

Country

Locality

Application Process

Organization

Organizational Unit

The following object classes are expected to be generally useful in the creation of DIT leaf

entries:

Alias

Application Process

Application Entity

DSA

Device

Group of Names

Organizational Person

Organizational Role

Residential Person

11.6.6.2 OIW Directory Strong Authentication Directory Profile

11.6.6.2.1 Other Profiles Supported

This profile is used in conjunction with the OIW Directory Common Application Directory

Profile.

11-6
December '89

11.6.6.2.2 Standard Application Specific Object Classes

The following object classes are expected to be generally useful for applications to support

strong authentication:

• Strong Authentication User

• Certification Authority

11.6.7 Restrictions on Object Class Definitions

An object class may not be defined as a subclass of itself, as the chain of superclasses of such an object class would be a closed loop, isolated from all other object classes, specifically

Top. Such isolation is clearly illegal.

11.7 PRAGMATIC CONSTRAINTS

This section describes pragmatic constraints to which a conformant implementation shall adhere in addition to those specified in the Directory Documents. The pragmatic constraints can be divided into two major areas. The first includes those aspects of pragmatic

constraints which apply to scope of service (see sec. 11.7.1 and sec. 11.7.2). The second

includes those aspects of pragmatic constraints which are specific to particular attribute

types (see sec. 11.7.3).

11.7.1 General Constraints

11.7.1.1 Character Sets

It is a requirement to support all character sets and other name forms defined in the Directory Documents, Part 6. Those character sets include:

• T.61

• PrintableString

• NumericString

11.7.1.2 APDU Size Considerations

In the process of chaining requests it is possible that a chaining DSA may receive, invoke or return APDUs that exceed its capacity. It is a minimum requirement that invoke APDUs

and return result APDUs shall be accepted unless they exceed .32767 octets in size; in this case they may be discarded as illustrated in the right side of figure 11.4 (page 11 - 8), and

an "unwillingToPerform" error reporting service shall be used.

11-7
December '89

DSA may pass on DSA may discard

Figure 11.4. APDU Exchange.

11.7.1.3 Service Control (SC) Considerations

This agreement recognizes that DUAs may automatically supply defaults for any SC

parameter. The choice of default values selected (if any) is seen to be a matter of local policy and consumer needs.

11.7.1.4 Priority Service Control

Priority is specified as a service control argument in the Directory Documents. The

following statements represent a clarification of the semantics that may be used by a DSA

in interpreting and operating on this parameter.

The logical model in figure 11.5 ( page 11-9) may be considered as an example by

DSAs that implement this Service Control. In figure 11.5, note that:

• the DSA maintains three logical queues corresponding to the three priority levels;

• the DSA Scheduler is separate and distinct from any scheduling function provided by

the underlying operating system or control program services;

• the DSA Scheduler presents jobs to the Underlying Operating Services for execution

and always presents jobs of a higher priority before those of a lower priority;

• the DSA Scheduler will not preempt a request once it has been passed to the underlying

operating system service.

11.7.2 Constraints on Operations

There are no overall constraints upon service arguments or results except those implied in section 11.7.1.2 of this document.

11.7.2.1 Filters

It is required that DSAs, at a minimum, support 8 nested "Filter" parameters, and a total limit of 32 Filter Items. If these hmits are exceeded, the recipient of that SearchArgument

may return the ServiceProblem "unwillingToPerform"

.

11-8
December '89

High

Medium

Low

1

DSA

Scheduler

Underlying

Protocol Services

Underlying OS

Services

Figure 11.5. Logical DSA Application Environment.

11.7.2.2 Errors

There are no constraints upon any Error service except the APDU size limit as defined in Section 11.7.1.

11.7.2.3 Error Reporting - Detection of Search Loop

A search operation may encounter a looping situation when the search encompasses "wholesubtree", and an alias is encountered which is a superior to some other subtree that has

been encountered during the search. DSAs should be able to detect this situation. One possible method is by:

1. Maintaining a list of the base objects of searches initiated as a consequence of Step 5 of Part 4, clause 18.7.2.2.1 of the Directory Documents (this may require an analysis

of the Tracelnformation field).

2. Determining whether a new base object is superior to any base object on this list. A new base object which would cause a loop in this way should be discarded (i.e. should

not cause a new search), but no error should be reported by an error-reporting service. The

circumstances should be logged so that it may be reported to an appropriate Administrative

Authority for rectification.

11.7.3 Constraints Relevant to Specific Attribute Types

Table 11.1 ( pages 11 - 36 and 11 - 37) gives pragmatic constraints associated with selected attribute types specified in the Directory Documents; many of these constraints also appear

and are the same in the CCITT version of the Directory Documents. Each constraint in Table 11.1 is given in terms of a length constraint. The length constraint for a given attribute

11-9
December '89

value is the number of units which a sending entity shall not exceed and which a receiving

entity shall accept and process. A sending entity need not be capable of sending attribute

values as large as the length constraints.

Note that in table 11.1 the length constraint for strings is expressed as the number of

allowable characters.

In addition to the constraints given in table 11.1, the following constraints apply to alphabets and integer values.

• Alphabets: T.61 Strings used as attribute values shall only encode graphic characters

and spaces. They shall not contain formatting characters (such as subscript) or other

control characters.

• Integer Values: DSAs shall be required to "pass through" encoded integer attribute

values of arbitrary length (e.g., when chaining a Directory operation). No Directory

component (i.e., DUA or DSA) shall be deemed non-conformant if it encodes integer

attribute values of arbitrary length.

Components of the Directory are required to support (for storage and processing), as a minimum, integer attribute values encoded in 4 octets.

11.8 CONFORMANCE

The following sections will describe various aspects of Directory conformance. It should

be noted that conformance to the various ASEs and conformance to the Authentication

Framework are viewed as separate issues and are presented in that context.

11.8.1 DUA Conformance

Conformance requirements for DUAs are adequately specified in the Directory Documents,

Part 5, clause 9.1 and the Directory Access Profile (see sec. 11.8.6). It should be noted

that the DUA conformance is based on DAP Protocol and not the User Interface. Not all options available in the standard need to be made available to the user of the DUA.

It is recognized that DUAs will be widely differing in nature:

• Some are intended to support human users, some application users

• Particular DUAs may not support particular operations because the application that

they support has no requirement; others will be general purpose, and will support all operations.

• Some DUAs will have a fixed view of the Directory content and structure, reflecting

the usage of The Directory by a particular application; others will have a more flexible view which can be adapted to new usages.

• Some DUAs will provide automatic referral services with automatic establishment and

release of associations; others will place the burden on the user.

11 - 10
December '89

• Some DUAs will provide a variety of authentication means; others will support no

authentication

• Some DUAs will handle operations synchronously; others will have the capability of

maintaining several identifiable dialogues with The Directory at one time.

In the next section, different types of DSAs are discussed. The DUA is independent of

the type of DSA it is communicating with and does not need to know what type of DSA it

is communicating with.

11.8.2 DSA Conformance

Basic conformance requirements for a DSA are defined in the Directory Documents, Part 5, clause 9.2. Some of the terms used to describe DSA conformance are summarized below.

• Centralized: A centralized DSA is defined as one that contains its entire relevant DIT;

it follows that it will not make use of the DSP or generate referral responses. Since

this model only contains a single DSA it is not subject to DSA interworking issues and will always provide a consistent level of service and results. A centralized DSA

shall be fully "protocol" conformant to the DAP.

• Cooperating: In a distributed directory, responsibility for various portions of the DIT

may be "distributed" among multiple DSAs. On a per operation basis we define a DSA to be holding when it is responsible for the fragment of the DIB in which a given

entry will appear if it exists; we define a DSA to be propagating when it is unable to complete the name resolution process.

All DSAs shall be capable of acting as a holder and a propagator.

11.8.3 DSA Conformance Classes

A DSA implementation shall satisfy the conformance requirements as defined in the Directory Documents, Part 5, section 9.2, and shall support the "Versions" argument of "Bind".

Per the conformance section of the Directory Documents, a DSA shall conform to the

abstraxrt syntax of the attribute types for which conformance is claimed. These attribute

types shall include those required by section 11.6.3 of this Implementor's Agreement.

Additionally, an implementation conformant to these agreements shall state which of the

following conformance classes it implements:

• Conformance Class 0 - Centralized DSA

A DSA conformant to this class only supports the DirectoryAccessAC.

As the performance of Search and List operations can consume significant resources, the policies of some centralized DSAs may be such that these operations will not be performed. For these cases, the reply to requests for such operations would be a

ServiceError with the "unwillingToPerform" ServiceProblem.

11 - 11
December '89

• Conformance Class 1 - Distributed DSA

A DSA implementation conformant to this class shall implement all the operations in the ASEs that are part of the Application context for which it claims conformance. It shall support the DirectoryAccessAC and it may optionally support the DirectorySystemAC.

DSAs conformant to these Agreements shall support the OIW Directory Common Application Directory Profile. In addition, DSAs may optionally conform to the OIW Directory

Strong Authentication Directory Profile. Future versions of these Agreements may allow

additional possibilities for minimal profile conformance.

11.8.4 Authentication Conformance

A Directory System may choose to implement various levels of authentication (Directory

Documents, Part 8). We define the following levels of authentication in the DS:

• No authentication at all; (None)

• Simple Uncorroborated: identification without verification

• Simple Uncorroborated authentication with verification: verified identification

without a password.

• Simple Corroborated authentication: verified identification with a password; in- tended to make masquerading difficult.

• Strong authentication: identification with verification using cryptographic techniques

intended to make masquerading, in practical terms, nearly impossible.

The "Authentication Framework" document describes the specific goal of each authentication level; listed below are several practical uses of the various levels. ^

Simple Uncorroborated authentication may be desired to maintain access

statistics or in a private network where the initiator is implicitly trusted and there

is no need to incur the additional overhead of more sophisticated authentication

methods.

Simple Corroborated authentication may be necessary in situations where

strong authentication is not practical, (i.e., international connection, no knowledge of algorithms in use, etc).

Strong authentication will be required for secure environments.

A DSA that implements Simple Corroborated authentication will check the user pass- word by means of a compare operation on the user's entry. If no user password is supplied

(Simple Uncorroborated authentication) the DSA will validate the presence of the entry for

^ It is the case that some DSAs containing public information may not require authentication.

11 - 12
December '89

the user, by a read operation or otherwise. The authentication will fail if the password is incorrect or if the user's entry does not exist. A DSA that implements Simple Uncorroborated authentication without verification will accept simple credentials without validating them.

Implementations claiming conformance shall, as a minimum, implement None and Simple Uncorroborated authentication without verification.

11.8.5 Directory Service Conformance

The following sections will describe various aspects of Directory conformance. Conformance

to the Authentication Framework is viewed as a separate issue from conformance to the rest of the Directory document and is presented in that context.

Directory Profiles are broken into two sections. Service support specifies the level of

support for operations and errors. Protocol support specifies the protocol elements required

for implementations which claim conformance to specified operations.

To specify the support for operations and errors, two classifications are used as follows.

1. r: required

The operation shall be implemented and the respective error shall be handled for conformance to these agreements. For DUAs, required means:

• For ARGUMENT parameters, create the DAP protocol elements to convey the

service request to the DSA.

• For RESULT and ERROR parameters, accept the DAP protocol elements.

For DSAs, required means:

• For ARGUMENT parameters, accept the protocol elements when received and

create the protocol elements when acting as a requesting DSA.

• For RESULT and ERROR parameters, be able to convey all possible results when responding in either the DAP or DSP protocols and when receiving results,

perform additional processing as defined for cooperating DSAs.

2. n: not required

It is left to implementations as to whether the operation or error is implemented or

not.

To specify the support for protocol elements, four classifications are used as follows.

1. M: mandatory

Generation of element is a mandatory static conformance requirement (i.e., a confor- mant implementation shall be capable of generating the element).

Generation of element is a mandatory dynamic conformance requirement (i.e., the

element shall be present in all instances of communication which use the element).

11 - 13
December '89

The terms static conformance and dynamic conformance are defined in ISO 9646-1,

"OSI Conformance Testing Methodology and Framework, Part 1: General Concepts."

2. G: generate

Generation of element is a mandatory static conformance requirement.

Generation of element is a conditional dynamic conformance requirement; the condition is: Where a DSA is a propagating DSA, it shall be capable of generating the

protocol element as received in related APDUs received from other DSAs.

Where the DSA is a holding DSA, it shall be capable of creating all possible

values of a protocol element unless otherwise noted in the "Comments" hne.

3. S: support

When receiving protocol elements, implementations of these agreements shaJl be ca- pable of accepting these elements without error. Actions specified in the Directory

documents and in these agreements shall be taken.

4. O: optional

When generating protocol elements:

• Generation of element is an optional static conformance requirement. If the

implementor claims support for the corresponding Directory capability, then the

implementation shall be capable of generating the element.

• Generation of element is an optional dynamic conformance requirement. If the

implementor claims support for the corresponding Directory capability, then the

element shall be present in instances of communication which use the element

(except where defaults allow otherwise).

When receiving protocol elements, implementations of these agreements shall be capable of accepting these elements without error. However, actions specified in the base

standard and in these agreements may be taken but are not required.

Where protocol elements are nested, the classification of the nested protocol elements is of relevance only when the immediately containing protocol element is generated. The

classification of the protocol elements at the highest level is relative with respect to support

of the operation.

Also note that in table 11.3, some rows contain two support classifications in the DSA

column. In such cases, the support classification in parentheses applies to centralized DSA's

only. When there is only one support classification given, it applies equally to centralized

and non-centrahzed DSA's.

11.8.6 The Directory Access Profile

This agreement requires implementations of the DUA to provide access to the Directory

Services as defined in the DUA column in table 11.2. For the services in table 11.2 which

are supported, these agreements further require DUAs to support the protocol elements as defined in the DUA column in table 11.3 (parts 1 - 7).

11 - 14
December '89

These agreements require implementations of the DSA to support the Directory Services

as defined in the DSA column in table 11.2 (page 11 - 40). These agreements further

require DSAs to support the protocol elements as defined in the DSA column in table 11.3. Table 11.3 is listed in seven parts (page 11-41 through page 11 - 47). Note that the

requirements for a centralized DSA and a cooperating DSA are different.

11.8.7 The Directory System Profile

These agreements require implementations of distributed DSAs which provide DSP to sup- port the responder role for services as defined in table 11.4 (page 11 - 48). Further, these

agreements require DSAs to support the protocol elements as specified in table 11.5. Table 11.5 is listed in nine parts (page 11-49 through page 11 - 57).

DSAs are required to support the requestor role for all the services as defined in table 11.4

if conforming to the chained mode of interaction.

11.8.8 Digital Signature Protocol Conformance Profile

Table 11.6 on page 11-58 and table 11.7 on page 11-58 provide information on the digital

signature protocol conformance profile.

Note that elements in CommonArguments and CommonResults SecurityParameters that

are not specified in table 11.6 and table 11.7 are covered in the Directory Service Protocol

Support (table 11.5) and Directory Access Protocol Support (table 11.3).

11.8.9 Strong Authentication Protocol Conformance Profile

table 11.8 on page 11-59 and table 11.9 on page 11-60 provide information on the strong

authentication protocol conformance profile.

11.9 DISTRIBUTED OPERATIONS

The following requirements apply to DSAs supporting distributed operations:

DSAs supporting authentication (e.g., simple authentication by name and pass- word) shall be able to invoke DSP operations to carry out authentication by

reference to other DSAs. Thus all such DSAs shall support the DSP protocol.

The requirement is implied by the Directory Documents.

11.9.1 Referrals and Chaining

It is recommended that a DSA which has chained a request act upon any referrals it receives

rather than returning them to the requestor if the "preferChaining" service control is present.

11 - 15
December '89

11.9.2 Trace Information

A Tracelnformation vaJue carries forward a record of the DSAs which have been involved in the performance of an operation. It is used to detect the existence of, or avoid, loops which

might arise from inconsistent knowledge or from the presence of alias loops in the DIT.

Each DSA which is propagating an operation to another, adds a new item to the trace information. If the propagation of a Search operation involves the creation of a new Search

(cf Directory Documents, Part 4, clause 18.7.2.2.2), the trace information shall not be reset, but the full trace information for the overall Search operation to the point where the new Search was generated shall be included in the new Search.

11.10 UiNDERLYING SERVICES

This section specifies requirements over and above those given in the Directory Documents.

11.10.1 ROSE

It should be noted that support of "abandon" implies support of operation class 2.

11.10.2 Session

All directory implementations are required to support Session Version 2.

11.10.3 ACSE

The A-ABORT service is required by association-accepting DSAs to escape unwanted associations, which, under the ROSE protocol, they cannot release. In all other cases (associationinitiating DSAs and DUAs) it may be preferable (though not required) to escape associations

using UNBIND rather than abort.

The aborting DUA or DSA may optionally use the user information field of the AABORT. Such information, however, is only meaningful for diagnostic purposes and its use

is not covered by these Agreements.

11.11 ACCESS CONTROL

Guidelines relating to access control can be found in Annex F of the Directory Documents,

Part 2.

11.12 TEST CONSIDERATIONS

This section outHnes some items that implementors may wish to consider in terms of testing

expectations; additionally, future conformance testers may wish to consider these items

when developing tests.

11 - 16
December '89

11.12.1 Major Elements of Architecture

One important aspect of testing is to confirm the correct behavior of DSAs and DUAs with

respect to major elements of the directory architecture.

Such major elements include:

• Conformance Statement

• Distinguished names (e.g., name resolution, equivalence of various forms)

• Entries and Attributes (e.g., accessibility by operations, compliance with rules)

• Handling of distributed operations (e.g., naming contexts and knowledge)

• Schemas — Structure rules (e.g., storage and maintenance of structure and of naming rules) — Object classes and sub-classes (e.g., storage and extension of rules for object

attributes) — Attribute types (e.g., storage and maintenance of syntax classes and rules for multi or single valued attributes) — Attribute syntax (e.g., maintenance and support for attribute value testing and

matching, to specification for a defined set of attribute types)

• Operations — all operations — correct function — correct result — correct responses

• Aliases (e.g., correct resolution, error responses)

• Authentication and Access Control (e.g., limitation of modify access)

• ROSE (e.g., correct handling of invokes, results, rejects, and invoke ids)

• ACSE (e.g., association establishment / refusal for invalid application contexts, etc.)

11.12.2 Search Operation

Testing of support for filter items should be reasonable. It is not expected that DSAs will be able to handle worst case testing in this area.

11.13 ERRORS

This section provides clarification of the semantics of various operation errors and implementation guidelines on their usage.

11 - 17
) December '89

11.13.1 Permanent vs. Temporary Service Errors

This section provides some clarification regarding the usage of the Service Errors busy,

unavailable, and unwillingToPerform.

The error busy is particularly transient. It is returned when one or more of The Directory's internal resources are being used to their capacity and, hence, the requested operation

cannot, for the moment, be performed. The Directory should be able to recover from this type of resource depletion after a short while.

The error unavailable is also temporary but somewhat less transient. It indicates that

The Directory (or some part of it) is currently unavailable and may continue to be unavailable for a reasonably long period of time. For example, this error is returned when

a given DSA is functionally disabled, or when a specific part of the DIB is undergoing

reconfiguration.

The error unwillingToPerform has a permanent connotation. It indicates that The Directory cannot perform the requested operation because it would require resources beyond

its capacity. For example, this error may be returned by a DSA if satisfying a request would

result in the generation of an APDU in excess of 32767 octets.

11.13.2 Guidelines for Error Handling

11.13.2.1 Introduction

This subsection provides a recommended mapping of error situations which may be encountered to ROSE Rejects or to the errors provided in the DAP and DSP protocols of the

Directory Documents.

The Directory Documents are not adequately definitive about the handling of errors. In

this document, more exphcit guidehnes are given.

Error situations are defined by:

• Symptom (i.e., the manner in which the error was detected).

• Situation (i.e., the circumstance or phase during which the error was detected. For each possible situation, the error-handling procedure needs to be defined).

11.13.2.2 Symptoms

Table 11.10 (page 11 - 61 to page 11 - 63) describes a set of symptoms; the set is not

necessarily exhaustive. Each is identified by a title which is used later in describing error

actions. The title used for each symptom is not intended to imply any particular usage in a particular implementation.

11.13.2.3 Situations

Table 11.11 (page 11-64) identifies recognized situations within which particular symptoms may give rise to distinct error actions.

11 - 18
December '89

11.13.2.4 Error Actions

Table 11.13 (page 11 - 66 to page 11 - 71) summarizes specific error actions for each

possible combination of symptom and situation. Symptoms are described in section 11.13.2.2 and situations are described in section 11.13.2.3. Each entry in table 11.13 corresponds to the symptom in the left-most column and the

situation given in the column header. Each entry may specify:

• a specific error action. The error action is described using the notation shown in table 11.12.

• a specific error action and a relevant note. The note will be indicated by a number

enclosed in parentheses. The notes can be found on page 11 - 72.

• only a relevant note.

• a blank (which indicates the corresponding combination of symptom and situation is not meaningful in the context of these Agreements).

The entries in table 11.13 which specify a specific error action will do so using the

notation shown in table 11.12 (page 11 - 65).

11.13.2.5 Reporting

In addition to the use of error-reporting services, DSAs should implement logging ser- vices to assist in management of the Directory. The list below describes classes of error which should be logged. Note that the list is not necessarily complete.

1. Errors indicating attempted breaches of security.

2. Errors indicating local software or hardware malfunction.

3. Errors indicating malfunction or other unacceptable behavior on the part of the invoker

of an operation.

4. Errors indicating loss of chaining service by another DSA.

5. Error conditions that would be difficult to diagnose with the level of detail supplied

over the protocol.

6. Aborts and other exceptional communications events.

The form and accessibihty of any such logs is for further study.

11.14 Specific Authentication Schemes

This section describes identified authentication algorithms. Use of algorithms in this section

is not mandatory. Use of algorithms other than those described in this section or described

in the Directory Documents is by bilateral agreement.

11 - 19
December '89

11.14.1 Specific Strong Authentication Schemes

This section provides information on one alternative to the RSA digitcJ signature scheme.

The alternative is identified as the "ElGamal" digital signature scheme. Future contributions

may result in other alternatives being added to this section.

Implementors may choose to provide digital signature capabihty based on RSA, ElGamal,

or some other scheme appropriate for use in the OSI Directory environment.

It should be noted that use of RSA is governed by U.S.A. patent law.

11.14.1.1 ElGamal

The information in this section includes a tutorial description of the ElGamal scheme

for digital signature using the notation defined in the Directory Documents, Part 8. It is intended that much of the tutorial information provided in this section will be moved to the

security agreements sometime in the future.

11.14.1.1.1 References

[ELGA85] ElGamal T., "A Public Key Cryptosystem and a Signature Scheme Based on

Discrete Logarithms," IEEE Trans, on Inform. Theory, vol. IT-31, No. 4, July 1985.

[DIFF76] Diffie W., Hellman M., "New Directions in Cryptography," IEEE Trans. Inform.

Theory, vol. lT-22, Nov. 1976

[COPP86] Coppersmith, D., Odlyzko, A., Schroeppel, R., "Discrete Logarithms in GF{p),"

Algoriihmica, vol. 1, 1986.

[McC179] McClellan, J., Rader, C, Number Theory in Digital Signal Processing, PrenticeHall, 1979.

[PATT87] Patterson, W., Mathematical Cryptology for Computer Scientists and Mathematicians, Rowman & Littlefield, 1987. [ODLY] Odlyzko, A., "On the Complexity of Computing Discrete Logarithms and Factoring

Integers," to appear in Fundamental Problems in Communication and Computation, B. Gopinath and T.Loven, Eds., New York, NY:Springer.

[ODLY84] Odlyzko, A., "Discrete Logarithms in Finite Fields and Their Cryptographic

Significance," in Advances in Cryptology, Proceedings of EUROCRYPT 84- New York,

NY:Springer-Verlag, pp. 224-314.

[ELGA85b] ElGamal, T., "A Subexponential-time Algorithm for Computing Discrete Logarithms over GF(p2);' IEEE Trans. Inform. Theory, vol. IT-31, July 1985.

[SIER88] Sierpinski, W., Elementary Theory of Numbers, North-Holland 1988.

[RFC1115] Linn, J., Privacy Enhancement for Internet Electronic Mail: Part III - Algorithms, Modes, and Identifiers, RFC-1115, August 1989, lAB Privacy Task Force.

11 - 20
December '89

11.14.1.1.2 Background

The ElGamal digital signature scheme is based on earlier work done by Diffie and Hellman

[DIFF76] in which it was suggested that a likely candidate for a one-way function is the

discrete exponential function

f{x) = (mod p) (1) where x is an integer between 1 and p— 1 inclusive, where p is a very large prime number, and

where a is an integer such that 1 < a < p and {a mod p, mod p, • • , a''"^ mod p} is equal

to the set {1, 2, • • • ,p — 1}. In algebraic terminology, such an a is called a primitive element.

References on the topic of primitive roots and elements are [McC179] and [PATT87].

Now, in the real number system, if y = a^, then by definition of the logarithm we can

solve for x using x = logj^(y). The same idea extends to solving eq (1) for x so that inverting

f{x) requires calculating discrete logarithms. The reason Diffie and Hellman suspected eq

(1) is one-way is that for suitable p, it is computationally difficult to invert f{x). According

to the current state of the art, computing discrete logs for suitable p has been found to require a number of operations roughly equivalent to exp(Vc6b6) (2)

where b is the number of bits in p, and c is estimated at c = .69 according to [ODLY]. This can be compared to only about 2 log2 p multipUcations for discrete exponentiation. If in fact the best known algorithm for computing discrete logs is near optimal then Expression (2)

is a good measure of the problem's complexity (for a properly chosen p) and the discrete exponential function has all the qualities of a one-way function as described by Diffie and

Hellman.

11.14.1.1.3 Digital Signature

• Private Key: Xs denotes the private key for user X. Xs is a randomly chosen integer

which user X keeps secret.

• Public Key : Xp denotes the public key for user X and is calculated using the corre- sponding private key such that

Xp = a^s (mod p) (3)

where — p is a prime satisfying the requirements listed in section 11.14.1.1.5. — a is a primitive element mod p. — Note that p and a could be used globally, but because they should be easily

changeable (see sec. 11.14.1.1.5 for information about why these two parameters

should be easily changeable) it would probably be preferable for each user to choose his/her own p and a. If users choose their own, then p and a must be

made available to the recipient for use in the signature verification process.

• Signing Procedure: Suppose user A wants to sign a message intended for recipient B.

The basic idea is to compute a two part signature (r, s) for the message m such that

a''^"'^ = {ApYr' (modp) (4)

11 - 21
December '89

where /i is a one-way hash function.

Compute the signature (r,s) as follows.

1. Choose a random number k, uniformly between 0 and p-1 such that k and p-1

have no common divisor except 1 (i.e., gcd(fe,p— 1) = 1).

2. Compute r such that

r = a* (mod p) (5)

3. Use r to solve for the corresponding s as follows.

(a) rewrite eq (4) using eq (5) and the definition of the public key to get

Combining exponents, get

eq (7) implies that

h{m) = {As)r + ks (mod p-1) (8)

Note that eq (8) has a single solution for s because k was chosen such that

gcd(ib,p- 1) = 1. See [SIER88] for supporting theorem.

(b) now solve for s and get

s = I{h{m) - {As)r) (mod p-1) (9)

where / is computed such that k * I = 1 (mod p — 1). The ElGamal signature is comparable in size to the corresponding RSA signature.

11.14.1.1.4 Verification

The recipient receives Ap,m,r,s,a, and p and computes both sides of eq (4) and then

compares the results.

11.14.1.1.5 Known Constraints on Parameters

The following list of constraints is the result of a search of current literature and may not be complete.

1. p must be prime

2. p must be large.

Note that Expression (2) can be used to speculate on the level of security afforded by

cryptosystems based on the discrete log problem. Breaking the ElGamal scheme has

not been proven to be equivalent to finding discrete logs, but if we assume equivalence

then we can estimate how large p should be for a desired level of security. For instance, suppose we wanted to use Expression (2) to decide how large p should

be so that we can be reasonably sure the system cannot be broken (using the best

11 - 22
December '89

known algorithm) in a practical amount of time. To be on the conservative side, we

decide we want to protect against a special purpose machine that can perform 10^^ operations per second. Specifically, we want to know how large p should be so that

such a machine would take at least one year to break the system.

In one year, the hypothetical machine can perform 3 x 10^^ operations. To find the

size of the desired p, solve the following equation for b.

We get b « 606. This is the number of bits in the desired p. So, the magnitude of the

desired p is about 2^°^ which is roughly 266 x 10^^°.

Hence, to be reasonably sure of attaining the desired level of security, we find a prime

number greater than 266 x 10^*° which satisfies all the other criteria listed in this section. Our confidence, however, is strictly based on the assumption that breaking

ElGamal is as difficult as finding discrete logs and the assumption that the best known

algorithm for finding discrete logs is near optimal.

3. p should occasionally be changed. This requirement is discussed in [ODLY84] and is related to the discovery of new algorithms for computing discrete logarithms in GF(p).

4. p — 1 must have at least one large prime factor. This requirement is discussed in [ODLY84] and is imposed by the Silverman-Pohlig-Hellman algorithm which computes discrete logarithms in GF{p) using on the order operations and a comparable

amount of storage, where r is the largest prime factor in p — 1.

5. p should not be the square of any prime. A subexponential-time algorithm for computing discrete logarithms in GF{p^) has been found. See [ELGA85b] for details.

11.14.1.1.6 Note on subjectPublicKey

The ASN.l data element subjectPublicKey, defined as BIT STRING in Annex (G) of

Directory Documents, Part 8, should be interpreted in the case of ElGamal as being of type:

SEQUENCE {INTEGER, INTEGER}

where the first integer is the Arithmetic Modulus and the second is the primitive element

for the finite field. The sequence is represented by the ASN.l Basic Encoding Rules.

Implementors should take note that the size of the integers used for these parameters is expected to exceed the pragmatic constraints specified for integers by the upper layers SIG.

11.14.1.2 One-Way Hash Functions

11.14.1.2.1 SQUARE-MOD-N Algorithm

Recent research regarding the square-mod-n one-way hash function described in Annex D

of the Directory Documents, Part 8, has revealed that the function is not secure. Its use, therefore, is discouraged.

(10)

11 - 23
December '89

11.14.1.2.2 MD2 Algorithm

MD2 is a one-way hash function and is described in [RFC 11 15]. Implementors should note

that the use of MD2 may be subject to license agreements.

11.14.1.2.3 Study of Other One-Way Hash Functions

The Directory SIG is studying the applicability of alternative one-way hash functions. Currently, this work includes review of SNEFRU; the Working Implementation Agreements

report the status of the work.

11.14.1.2.4 Use of One-Way Hash Functions in Forming Signatures

MD2 may be used to form digital signatures in conjunction with RSA or ElGamal.

11.14.1.3 ASN.l for Strong Authentication Algorithms

This section defines object identifiers assigned to authentication algorithms. The defini- tions take the form of the ASN.l module, "OIWAlgorithmObjectldentifiers".

OIWAlgorithmObjectldentif iers {iso(l) identif ied-organization(3)

oiw(14) dssig(7)

OIWAlgorithmObjectldentif iers (1)}

DEFINITIONS : := BEGIN

EXPORTS

iad2. md2WithRSA, elGamal, md2WithElGamal

;

IMPORTS

authent icat ionFramework

FROM UsefulDefinitions {joint-iso-ccitt ds(5) modules (1)

usefulDef initions (0)

}

ALGORITHM FROM Authent icat ionFramework

authent icat ionFramework

;

— categories of object identifiers

algorithm OBJECT IDENTIFIER : := {iso(l) identified-organization(3)

oiw(14) dssig(7) algorithm(2)>

encriptionAlgorithm OBJECT IDENTIFIER : := {algorithm 1}

hashAlgorthm OBJECT IDENTIFIER ::= {algorithm 2}

signatureAlgorithm OBJECT IDENTIFIER ::= {algorithm 3}

11 -24
September 1990 (Stable)

— algorithms

md2 ALGORITHM

PARAMETER NULL

::= {hashAlgorithm I}

md2WithRsa ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 1>

elGamal ALGORITHM

I PARAMETER NULL

::= {encrypt ionAlgorithm 1}

I Editor's Note: Refer to the June 1990 Working Agreements for information reI garding why PARAMETER NULL is specified above for the elGamal encryption

I algorithm.

nid2WithElGamal ALGORITHM

PARAMETER NULL

::= {signatureAlgorithm 2}

END — of Algorithm Object Identifer Definitions

11.14.1.4 Note on the ENCRYPTED MACRO

I The value associated with the ENCRYPTED MACRO, as defined in Directory DocuI ments, part 8, clause 8.4 shall be interpreted in the ceise of ElGamal as being type:

, SEQUENCE{ INTEGER, INTEGER }

j The first integer in the sequence is r (see eq (5), sec. 11.14.1.1.3). The second integer is s

I (see eq (9), sec. 11.14.1.1.3).

11.14.2 Protected Simple Authentication

Protecting the user's distinguished name and password provides greater degrees of security

than where passwords are not protected.

The procedure for achieving this protection, referred to as protected simple authentication, is outlined in the Directory Documents, Part 8, clause 5.3. The approach by which

protected identifying information may be generated is outlined in the Directory Documents,

Part 8, clause 5.4. For the purpose of these agreements, fl and /2 as specified in the

Directory Documents, Part 8, clause 5.4 are identical MD2 one-way functions. The algorithms for implementation of the MD2 one-way function are described in [RFC1115] (see

11 - 25

September 1990 (Stable)

sec. 11.14.1.1.1). Note that the use of MD2 may be subject to licensing agreement. Use of

other algorithms for other one-way functions is by bilateral agreement.

User A generates Protected2 as specified in the Directory Documents, Part 8, clause 5.4. Authenticator2 is then conveyed to B in the form of SimpleCredentials. Table 11.14 on

page 11-73 shows the relationship between SimpleCredential fields and the elements of

protected simple authentication as shown in figure 2 of the Directory Documents, Part 8.

11.14.3 Simple Authentication

There are two major classes of authentication supported by the Directory (i.e., simple and

strong authentication). Simple authentication is based on a password being passed between

the two associated entities (e.g., between a Directory User and a DUA, or between two

DSAs). In the case of interaction between a Directory User and a DUA, the pcissword is compared in some way with the password attribute in the user's entry in the Directory. In the case of interaction between two DSAs, this cannot be done since the DSA object class, as defined in the Directory Documents (Part 7, clause 6.14) does not contain a password

attribute.

To facilitate simple authentication between DSAs, it is recommended that a DSA have

local access to a list of one or more known DSAs, with a copy of each known DSA's password.

Maintenance of that information is done through the use of bilateral agreements between

DSA administrators.

11-25-1


December '89

11.15 APPENDIX A: MAINTENANCE OF ATTRIBUTE SYNTAXES

11.15.1 Introduction

The attribute types defined in the Directory Documents, Part 6, and listed in table 11.1 (page 11-38) have requirements, in DSAs which support them, for underlying algorithms

that:

• check attribute values for syntactical correctness and compliance with pragmatic constraints;

• match attribute values (comparing for equality, for matching substrings, and for relci- tive ordering).

11.15.2 General Rules

A DSA may receive a legitimately encoded attribute or AVA that is unsupported by the

DSA. If the DSA is not required to act on it, or to store it within an entry, it may handle

it by passing it on without error. Such attributes may also be used in search filter-item

definitions: in this case, no error is reported, but the filter-item shall be deemed to be

undefined for all entries in the DSA. This rule applies to occurrences of attributes in both

operation arguments and results.

Conversely, a DSA must return a suitable error if an operation requires it to act on or

store an attribute or AVA of type unsupported by the DSA. This constraint applies even

for AVAs that are contained in attributes that take names as values, since the DSA will be

unable correctly to match the attribute values without this attribute information.

11.15.3 Checking Algorithms

The subsections below give additional checks (beyond those directly implied by the Directory

Documents) which shall be applied to attributes before they are stored in the DSA.

11.15.3.1 distinguishedNameSyntax

Each component AVA must be checked, unregistered attribute types comprising an error; check also that no two AVAs in the same RDN have the same attribute type.

11.15.3.2 integerSyntax

Local implementations may apply local limitations.

11 - 26
December '89

11.15.3.3 telephoneNumberSyntax

The value of policing further rules is for further study (this applies also to telexNumber, tele- texTerminalldentifier, facsimileTelephoneNumber, GSFacsimileNonBasicParameters, xl21Address,

and iSDNAddress).

11.15.3.4 countryName

The value must be checked for compliance with IS03166: 1981 (E/F). (Note that from time

to time further codes may be allocated.)

11.15.3.5 preferredDeliveryMethod

The values of the integer elements should not be restricted.

11.15.3.6 presentationAddress

No further checks should be applied.

11.15.4 Matching Algorithms

Matching algorithms are conveniently defined in terms of a two-step process:

1. Take the checked reference value, and the value to be matched, and, if necessary, reduce them to a canonical (i.e., standard) form (normalization) appropriate to each

attribute syntajc.

2. Carry out the comparison in the specified way (e.g., equality, substrings or ordering)

using the appropriate rules for the value - character string, integer, boolean, etc.

Note that the lexical ordering of character strings (when supported) may be subject to local

rules. IMPORTANT NOTE: The combination of normahzation and comparison may be re- placed, in a particular implementation, by equivalent procedures. Additional notes on nor- medization are given below.

11.15.4.1 UTCTimeSyntax

If the "seconds" field is absent, it shall be inserted, and set to "00", and the form

converted to the "Z" form. Note. The normalization strategy does not match times where

the stored form omits the seconds field, and the compared form contains it, e.g.,

8804261919Z

880426191926Z

11 -27
December '89

(It might have been expected that these two forms, which coincide in time to within a few

seconds, would be considered identical.)

11.15.4.2 distinguishedNameSyntax

For each attribute value, carry out normahzation in accordance with the normalization

rules defined for the type (if registered); values corresponding to unregistered attribute types

are left unchanged at this stage.

11.15.4.3 caselgnoreListSyntax

To facilitate matching, particularly for substrings, normalization may be considered in terms of a representation which replaces the separate ASN.l elements by a single string with a delimiter.

11 - 28
December '89

11.16 APPENDIX B: GLOSSARY

The following abbreviations may be useful; not all are used within these agreements.

ACL Arrpss Control T<ist ACSE Asfinriation ("Innt.rnl SpTvirf^ Fllpmf^Tit. ADDMD x^Ulllliilo tl <X\>i\Ji\. LJil. CC t(JI jr iVlCUlClgdildl v JL/Ullldltl AETitle

APDU A nnlir;^ t.ion Protorr>l Tlafa Tin it. ASE ADDlication Servicp Klpmpnt

ASN.l Abstract Syntax Notation - 1 AVA Attribute Value Assertion

BRM

CA Certification Authority

CCTTT X lie. Ill tCl lL<XUI011<Xi XdCgid^li ClliU. XClC|^llL>ilC V^UllOUltCtul VC V^OIlillllu vCC CEN Oommittpf* v^i-/x 1 ixxxx u uv.r\^ for xv^x F^iirnripan j_j ux L/^^cl'XX N^nrmaliy.at.ion J. Y vyx xxxcvxxcyuritxvyxx CENELEC Committpf for Fluronean Normalization Klectroniaue

CEPT ^Committee I V^^^X XXXXXX V u \-rV^ ofV^X Kuronean J-J U X yj\^ UXX XPostsV<i3 and U>XX VX TeIer>honesl J. \^XV.r LrXX\^XX\rft9 I COS Corporation for Open Systems

DAP Directory Access Protocol

DIB Directory Information Base

DIT Directory Information Xree

DMD Dirpft.orv X^l 1 ifVyX V IVrfinacpmpnt IVX Cliil Ctt^V^ 1 llViii 11 U Dnm^iin^ X^ WlllCLlllO Tlirprf Arv Sv^tpm A cpnt

DSP Directory System Protocol

DUA Directory User Agent

EWOS Fliirnnpati J_J UX v/L/V^ CLXl Worlc^Hnn T T KJi. no11 WL/ for IWl Onpn^11 Svst.pm^ V O U V^lllo FTAM File Transfer, Access & Management

TNTAP XI ^ X XXX TnfprriT^pra ni lit V T'pi^nnipal A^^o^'i^itinn frir Tnir^rmAtirin Ppr*iTMPQRincr ismstn ISDN Integrated Services Digital Network

ISO/TEC Ttitppiifltiona Xll U^l llCLvl'h.'llOLl1 Oro"ani7atinn 1 gCl-lllCj dOlV^ll for XWX fitannarniyflt.ion uCxllUCtL Ul£iu>UlUll KTXV X LL TiOWPr lavpr^ of O^T rnonpl ilavpr^ l-4i MAP Ayi a n III a 1 11 Ti n o" A iit/^mati/^n Pi*i~*trt/*/^i IVldliUiclt. LUIlllg tVli HJHlclLl*Jli X HJtOCLJl iviessage nanaiing oy&ieiiio

NIST ^National 1 U/UXWXXIXX XXXOUXUUW' Institute ofVX Standards V CtiX X VX U>X VI 1^ and U<XX \X TechnoloETV X. V>\^XX XXV/XV^t»T NSAP Network Services Access Point

OSI Open Systems Interconnection

PKCS Public Key Crypto System

POSI Promotion for Open System Interconnection

PRDMD Private Directory Management Domain

PSAP Presentation Service Access Point

RDN Relative Distinguished Name

ROSE Remote Operations Service Element

SSAP Session Service Access Point

SIG Special Interest Group

SPAG Standards Promotion &; Application Group

TOP Technical and Office Protocols

TSAP Transport Service Access Point

11 - 29
December '89

UL Upper layers of OSI model (layers 5-7)

UPU Universal Postal Union

11 - 30
December '89

11.17 APPENDIX C: REQUIREMENTS FOR DISTRIBUTED

OPERATIONS

The following material is included for tutorial purposes, and does not represent material

additional to the Directory Documents. It is also not intended as a complete statement

of requirements (the Distributed Operations part of the Directory Documents should be

referred to for a complete treatment).

11.17.1 General Requirements

DSAs supporting distributed operations and claiming support of chaining must fully support

DSP, as defined by the Directory Documents. DSAs supporting distributed operations must

always be able to accept incoming DSP associations and invocations. DSAs claiming support

of chaining must support:

• Loop detection

• Loop avoidance

In passing on operations (when chaining or multi-casting), the original DAP-supplied

invocation must be passed on without change of content. In particular, there must be no

alteration in any way of any primitive content. The support of a facihty for returning cross-references (Directory Documents, Part 4, clause 10.4.1) is optional.

To ensure that tracelnformation can be analyzed properly, DSAs shall only possess names

that are compliant with the recommendations of the Directory Documents, Part 7 (including

Annex B).

11.17.2 Protocol Support

11.17.2.1 Usage of ChainingArguments

When using ChainingArguments: ^

• on^ma^or need not be used if requestor in CommonArguments is used;

• targetObjeci shall not be used unless the target object diff"ers from object/base object

(if it is present, object/base object are ignored for purposes of name resolution);

• operationProgress, tracelnformation, aliasDereferenced, aliasedRDNs, referenceType,

and timeLimit shall be generated, accepted, and used in accordance with the Directory

Documents;

• returnCrossReferences and info may optionally be generated, and shall always be ac- cepted.

^In this section, the names of protocol elements (within ChainingArgimients) are italicized.

11 - 31
December '89

11.17.2,2 Usage of ChainingResults

When using ChainingResults: ^

• crossReferences and info may optionally be generated, and shall always be accepted.

3 In this section, the names of protocol elements (within ChainingResults) are italicized.

11 - 32
December '89

11.18 APPENDIX D: GUIDELINES FOR APPLICATIONS USING THE DIRECTORY

11.18.1 Tutorial

11.18.1.1 Overview

Applications may have a requirement for Directory functionality. This tutorial provides

assistance to those groups intending to specify Directory usage for a specific apphcation

(e.g., Message Handling Systems).

11.18.1.2 Use of the Directory Schema

11.18.1.2.1 Use of Existing Object Classes

Applications wishing to use the Directory should have determined within a standard, Implementor's Agreements, or on a propriety basis, the relevant Directory schema for their objects. Consider the following two examples:

1. Network management applications may with to define a SMAE object class.

2. File transfer applications may with to define a File Store object class.

Groups should examine relevant standards to determine if application-specific object

classes or attributes have been already defined before considering any additional definition. These object classes and attributes may be found in a variety of places including a specific application standard (e.g., [Recommendation CCITT '88 X.402 | ISO 10021-2] and

the Directory Documents.). Standardized object classes and attributes should be strongly

considered before additional schema elements are created.

11.18.1.2.2 Kinds of Object Classes

There are effectively two kinds of object classes permitted within the Directory Documents: structural and auxiliary. The terms structural and auxiliary are used here for convenience when referring to particular kinds of object classes. The terms themselves are not defined in the Directory Documents.

Structural object classes have associated DIT structure rules (which control naming).

Entries of this object class type are intended to be instantiated in Directory entries. A

structural object class provides information on the base mandatory and optional content of a DIT entry.

An auxiliary object class provides information to enhance the mandatory and optional contents of entries. It is always used in conjunction with a structural object class. The object class hierarchy is formed as a result of the definition of structural object

classes, and the addition of auxiliary object classes.

11 - 33
December '89

For example, all object classes in the Directory Documents, Part 7, are structural except

for strongAuthentication User and certificationAuthority. These two object classes should

be considered auxiliary and used in conjunction with other, structural object classes.

11.18.1.2.3 Use of Unregistered Object Classes

The Directory Documents, Part 2, clause 9.4.1 provides a "special" form of object class called "unregistered." An unregistered object class is not assigned an object identifier. One of the uses for unregistered object classes is to provide a means of creating a single

Directory entry which logically represents a variety of object classes. Uses for unregistered

object classes include:

• Locally adding attributes to a predefined superclass;

• Locally making optional attribute types in a predefined superclass mandatory;

• Creating an object class derived from multiple superclasses, without needless proliferation of registered object classes.

For example, it may be advantageous to provide an entry which represents a person who

is both a MHS and a FTAM user.

Unregistered object classes may best be illustrated by example. Consider an entry which

represents a collection of company entries for Fizzy Company whose users have MHS O/R

addresses. Using the guidelines above, the Fizzy Company defines an unregistered object

class using the structural object class organizationalPerson from the Directory Documents,

Part 7, and the auxiliary object class mhs-user from the MHS standards [Recommendation

X.402 I ISO 10021-2] as follows:

lizzyCompanyPerson ::= OBJECT-CLASS

SUBCLASS OF orgeinizationalPerson, mhs-user

MUST CONTAIN {}

HAY CONTAIN {}

Note that no object identifier is assigned.

Also note that since there are not MUST or MAY CONTAIN's in the fizzyCompanyPerson Object Class, the last two lines of the object class assignment (i.e., "MUST CONTAIN

MAY CONTAIN ") are optional. As with the registered form of object classes, an unregistered object class always inherits all the attributes in any of its superclasses. There is no mechanism defined whereby a subclass may selectively inherit attributes from its superclasses. An unregistered object class always appears as a leaf in the Object Class tree, (i.e.. An

unregistered object class may not be a superclass of some other object class).

Using unregistered object classes in conjunction with multiple inheritance is useful as shown by figure 11.6 in which three ways of creating the same two object classes are shown.

Either three, four, or five registered object classes are used. Examples (a) and (c) in figure 11.6 are both better ways of defining the object classes than that in example (b), even though example (c) needs to use one more registered object

11 - 34
December '89

per mhs ae

\ / \ /

mhs-per [ur] mhs-ae[ur]

I per ae I per i

I I I I \ /

I mhs-per mhs-ae I mhs-per

mhs

\ /

mhs-ae

ae

Example a Excimple b Excimple c

[ur] = unregistered

per = person

mhs = mhs-user

ae = applicationEntity

Figure 11.6. Three Ways of Creating Two Object Classes.

class than example (b). This is because the multiple inheritance technique, used in examples

(a) and (c), enables a Directory User searching the Directory to easily create a filter to find

all entries that contain mhs-user attributes, based on a value in the object class attribute

(Each Directory entry contains a list of the object identifiers of the object classes it has

inherited from, so the filter would just have to find all entries that held the object identifier value of mhs-user).

Example (a), which uses three registered object classes, is better than example (c), which

uses five, because registering the extra two object classes does not provide any advantage

over not registering them, and the first method avoids needless proliferation of registered

object classes.

11.18.1.2.4 Side Effects of Creating Unregistered Object Classes

This section discusses two side effects of creating unregistered object classes.

1. When an unregistered object class is defined from a single superclass, there is no means available to distinguish between the two. Within the local scope for which

the unregistered class is defined, all relevant entries are considered to belong to the

unregistered class. The following is an example of this problem:

An object class of oCl(reg) has attribute type atl mandatory and at2 optional. An unregistered form of this, oCl(unreg) is created, which makes at2

mandatory. When an Add Entry operation is received with both attributes

present, the entry could belong to either form of oCl; it is indeterminate.

After the entry is added a Modify Entry operation is received which requests

the removal of attribute type at2. It is not clear if this operation should

succeed, or whether an object class violation should be reported. If the

attribute may be removed, then the entry belonged to the oCl(reg) object

class and the unregistered form never existed, otherwise if the attribute may

not be removed, then the entry belonged to oCl(unreg) and the registered

form no longer exists.

2. More than one unregistered object class cannot be defined from the same superclcLss(es)

for use within the same local scope, as there is no means available to distinguish the

11 - 35
December '89

classes from one another.

11.18.2 Creation of New Object Classes

If no appropriate object class is available, a new object class may be defined. This should

only be done if no standardized object classes and attributes can fulfill the requirements.

11.18.2.1 Creation of New Subclasses

Generally, an application-specific object class is defined as a subclass of a pre-existing Directory object class. These object classes are specified in the Directory Documents, Part 7. The subclass may be structural or auxiliary. Optional attributes of the superclass may be

made mandatory. New attributes may also be added.

For example, MHS has used the Directory structural object class applicationEntity to

derive the object class for their MHS-specific application entity MTAs.

If absolutely no relevant object class is available, an object class may be defined as a

subclass of the basic object class called "Top"

.

If no appropriate object class is available, a new object class may be defined. This

should only be undertaken if no standardized object class can fulfill the requirements. When

defining new object classes the object-class macro, as defined in the Directory Documents,

Part 2, clause 9.4.6, should be used.

If new subclasses are defined, suggested or required name forms may also be specified in text

.

11.18.2.2 Creation of New Attributes

If no appropriate attributes are available, a new attribute type may be defined. This

should only be undertaken if no standardized attributes can fulfill the requirements. When

defining new attributes the attribute macro, as defined in the Directory Documents, Part

2, clause 9.5.3, should be used.

11.18.3 DIT Structure Rules

Applications may desire to provide guidance on DIT structure rules and naming. As with

object classes, standardized or suggested structure (including naming) rules from the Directory Documents part 7, Annex B and application-specific standards should be consulted

before providing new structure rules. Annex B in the Directory Documents, Part 7, provides

guidelines on how to specify this information. Structure rules associated with superclasses

should be adopted wherever suitable.

11 - 36
December '89

11.19 APPENDIX E: TEMPLATE FOR AN APPLICATION SPECIFIC PROFILE FOR USE OF THE DIRECTORY

The template defined below should be used by OIW SIGs intending to specify Directory

usage. Such application specific profiles shall be contained in application specific chapters

of the OIW agreements. The information under each heading should be filled in (the text under each heading provides guidance on the intent of the section and should not be included

in the profile).

• PROFILE TITLE

Application specific profiles are named in the following way:

OIW <SIG-NAHE> <DESCRIPTOR> DIRECTORY PROFILE

(e.g., OIW DIRECTORY STRONG AUTHENTICATION DIRECTORY PROFILE )

• OTHER PROFILES SUPPORTED

Other OIW Directory profiles which are to be used by this specific application are listed here. Attributes, attribute sets, object classes and structure rules that are referenced

in these profiles need not be enumerated below.

• STANDARD APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS

Any attributes supported from the relevant standards. For example, the MHS SIG

might include mhs-or-address here.

• STANDARD APPLICATION SPECIFIC OBJECT CLASSES

Any object classes supported from the relevant standards. For example, the MHS SIG

might include mhs-user here.

• OIW APPLICATION SPECIFIC ATTRIBUTES AND ATTRIBUTE SETS

This, optional, component of this profile allows for the specification of OIW application

specific attributes and attribute sets. This section of this template should be used

rarely and with consideration that no standard profile or attribute/attribute set exists which can be used.

• OIW APPLICATION SPECIFIC OBJECT CLASSES

This, optional, component of this profile allows for the specification of OIW application

specific object classes. This section of this template should be used rarely and with

consideration that no standard profile or object class exists which can be used.

• STRUCTURE RULES

Guidance for t)IT structural rules, provided only when structure rules associated with

superclasses are not adopted. The Directory Documents, Part 7, Annex B provide an example and guideline to use in specifying this information.

11 -37
December '89

Table 11.1. Pragmatic Constraints for Selected Attributes (Part 1 of 2)

Attribute Type Content Constraints Primary

Source

Notes

Aliased Object Name Distinguished

Name

Note 3 (page 11-39)

Business Category T.61 or Printable

String

ub-business-category

128

CCITT

A.520

Common Name T.61 or Printable

String

ub-common-name

64

CCITT

V COA A. 520

Country Name Printable String 2 ISO

3166

Description T.61 or Printable

String

ub-description

1024

CCITT

X.520

About 1 screen full

Facsimile Telephone

Number

Facsimile Telephone

Number

ub-telephone-number

32

CCITT

X.520

Optionally includes G3

non-basic parameters

1 1 1 T~\T^^ r r\j*\i 1 n^ c ttc 1

International ISDN

L\ UIIIUCI Numeric String ub-isdn-address

11 fiu CCITT

X 590

E.164 Intemat'l ISDN

Number

Knowledge Information

T.61 or Printable

String

1024 NIST About 1 screen full

Locality Name T.61 or Printable

String

ub-locality-name

1 98

CCITT

Member Distinguished

IN dlllc

Note 3 (page 11 - 39)

Object Class Object Identifier 256 octets NIST

Organization Name T.61 or Printable

String

ub-organ iz at ion-name

64

coil i x.520

Organizational Unit

Name

T.61 or Printable

String

ub-organizational-unit- name 64

CCITT

X.520

Owner Distinguished

Name

Note 3 (page 11 - 39)

Physical Delivery

Office Name

T.61 or Printable

String

ub-physical-office-name

128

CCITT

X.520

Post Office Box T.61 or Printable

String

ub-post-ofRce-box

40

CCITT

X.520

Postal Address Postal Address ub-postal-line 6 ub-postal-string 30

CCITT

X.520

UPU

Presentation Address Presentation

Address

224 octets NIST Note 2 (page 11 - 39), ISO 7498.3 & X.200 Role Occupant Distinguished

Name

Note 3 (page 11 - 39)

See Also Distinguished

Name

Note 3 (page 11-39)

11 - 38
December '89

Table 11.1. Pragmatic Constraints for Selected Attributes (Part 2 of 2)

Attribute Type Content Constraints Primary

Source

Notes

Serial Number Printable String ub-serial-number

64

CCITT

X.520

State or Province

Name

T.61 or Printable

String

ub-state-name

128

CCITT

X.520

Street Address T.61 or Printable

String

ub-street-address

128

CCITT

X.520

Surname T.61 or Printable

String

ub-surname

64

CCITT

X.520

Telephone Number Printable String ub-telephone-number

32

CCITT

X.520

E.123

Teletex Terminal

Identifier

Teletex Terminal

Identifier

ub-teletex-terminal-id

1024

CCITT

X.520

Optionally includes Teletex non-basic pa- rameters (upper bound

ffs) Telex Number Telex Number ub-telex-number 14 ub-country-code 4

ub-answerback 8

CCITT

X.520

Contains sequence of

telex number, country

code, and answerback

Title T.61 or Printable

String

ub-title 64CCITT

X.520

User Password Octet String ub- user- password

128

CCITT

X.520

AUow long passwords

generated by machine

X.121 Address Numeric String ub-xl21-address

15

CCITT

X.520

X.121

Notes for table 11.1

1. The pragmatic constraints of these parameters are defined in other standards. We

will accommodate these values in our pragmatic constraints.

2. Presentation address is composed of "X" NSAP addresses, and three selectors, (20X -f- 32 -f- 16 + 16), e.g., i{ X = 1, this would be 84. These numbers are based on the most recent implementors' agreements. With 8 NSAP addresses this value is 224.

3. Pragmatic constraints are only applied to the individual components of DistinguishedName as defined in the Directory Documents, Part 2. Not all components of a DN will necessarily be understood by an implementation.

4. Implementors should be aware that constraints on Postal Address may not be suffi- cient for some markets.

11-39
December '89

Table 11.2. Directory Access Service Support.

Support

Classification

Operations and Errors DUA DSA Comments

- BIND and UNBIND -

DirectoryBind

DirectoryUnbind

r

r

r

r

- OPERATIONS -

- READ OPERATIONS - Read

Compare

Abandon

n

n

n

r

r

r (note 2)

- SEARCH OPERATIONS -

List Search nn

r (note 1)

r (note 1)

- MODIFY OPERATIONS - AddEntry

RemoveEntry

ModifyEntry

ModifyRDN

n

nn

n

r

r

r

r

- ERRORS - Abandoned

AbandonedFailed

AttributeError

NameError

Referral

SecurityError

ServiceError

UpdateError

(note 4)

(note 4)

(note 4)

(note 4)

(note 4)

(note 4)

(note 4)

(note 4)

r

rr

r

r (note 3)

r

r

r

Notes for table 11.2

1. As performance of Search and List operations can consume significant resources, the

policies of some centralized DSAs may be that such operations will not be performed.

For these cases, the reply to the requests for such operations would be ServiceError

with the "unwillingToPerform" Service Problem.

2. Reference Directory Documents, Part3, clause 9.3.6

3. Centralized DSAs would not generate referrals.

4. See EntrylnformationSelection information under Common Data Types (table 11.3, Part 6)

11 - 40
December '89

Table 11.3. DAP Protocol Support (Part 1 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

- BIND and UNBIND -

DirectoryBind

DirectoryBindArgument M s

credentials \j c•3 simple O s name G s

validity O o

password G s

strong O o See Strong Authentication Protocol Conformance Profile for re- quirements when strong authentication is supported.

externalProcedure O o

versions o s Supported value: vl988

DirectoryBind Result s G

credentials o G Shall be the same CHOICE as in DirectoryBindArgument.

simple o G

name s G

validity o O

password o O

strong o O See Strong Authentication Protocol Conformance Profile for re- quirements when strong authentication is supported.

externalProcedure 0 o

versions s o Supported value: vl988

DirectoryBindError s G

versions s O Supported value: vl988

ServiceProblem s G Supported value: unavailable

SecurityProblem s G Supported values: inappropriateAuthentication, invalidCredentials

DirectoryUnbind The DirectoryUnbind has no arguments.

11 - 41
December '89

Table 11.3. DAP Protocol Support (Part 2 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

- OPERATIONS, ARGUMENTS AND RESULTS -

- READ OPERATIONS - Read

ReadArgument M S

object M s

selection 0 s See note 2 on page 11 - 47. CommonArguments O s ReadResult S G

entry S M

^ommonrtesuiis c c

Compare

CompareArgument M S

object M S

purported M S

CommonArguments O S

CompareResult S G

DistinguishedName s G

matched s M

fromEntry s G

commonResults s G

Abandon

AbandonArgument M S

invokeld M S

AbandonResult S G

- SEARCH OPERATIONS -

List ListArgument M S

object M S

CommonArguments 0 S

ListResult S G

listlnfo S G

DistinguishedName s G

subordinates s M

Rel. DistinguishedName s M For the case where subordinates is empty set, RDN is absent. aHasEntry s G

fromEntry s G

partialOutcomeQualifier s G

CommonResults s G

UncorrelatedListlnfo s G(0)

ListResult s G See note 1 on page 11-47 for additioneJ information related to the DSA support cl2issification.

11 - 42
December '89

Table 11.3. DAP Protocol Support (Part 3 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

Search

SearchArgument M S

baseObject M s

subset O s

niter O s

searchAliases O s

selection O s CommonArguments O s SearchResult s G

searchinfo s G

DistinguishedName s G

entries s M

partialOutcomeQualifier s G

CommonResults s G

uncorrelatedSearchinfo s G (0)

SearchResult s G

partialOutcomeQuahfier s G

limitProblem s G

unexplored s G

unavailableCriticalExt s O

- MODIFY OPERATIONS -

A rlrlFnf rv AddEntryArgument M s

object M s

entry M s CommonArgument O s AddEntryResult s G

RemoveEntry

RemoveEntryArgument M s

object M s CommonArguments O s RemoveEntryResult s G

ModifyEntry

ModifyEntryArgument M s

object M s changes M s At least one entry modification must be supported.

addAttribute 0 s removeAttribute 0 s addValues 0 s removeValues O s CommonArguments 0 s ModifyEntryResult s G

11 - 43
December '89

Table 11.3. DAP Protocol Support (Part 4 of 7)

JT iUu^JCOl XJlclllCIlt

Support

Classification

v^UllilllCllUo r»TT UU AA JJoA

IVlOU1 1 y rvJ-/ iN

A/f rir^ifvR T^IV A roriimf^Tit' M S

object M S

newRDN M

O s O G

ModifyRDNResult c

b G

- ERRORS AND PARAMFTFRS -

Abandoned

AbandonFailed

problem S M

operation S M

AttributeError

object S M

problems S M Min. 1 error (See Directory Documents, Part 3, clause 12.4.2.2) type S M

value S G

NameError

problem S M

matched S M

Referral candidate s G

11 - 44
December '89

Table 11.3. DAP Protocol Support (Part 5 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

SecurityError

problem s M

ServiceError

problem s M

UpdateError

problem s M

- COMMON ARGUMENTS / RESULTS - CommonArguments

ServiceControls o s

SecurityParameters o s See Section 11.8.8. certification-path o s name 0 s

time 0 s random o s

target 0 s

requestor o s OperationProgress 0 S(0)

nameResolutionPhase M s nextRDNToBeResolved O s aliasedRDNs 0 S(0)

extensions 0 s

identifier M s

critical O s item M s

CommonResults

SecurityParameters O G(0) See Section 11.8.8. certification-path 0 G

name 0 G

time 0 G

random O G

target 0 G

performer 0 G(0)

aliasDereferenced 0 G

11 - 45
December '89

Table 11.3. DAP Protocol Support (Part 6 of 7)

rrotocol Llement

Support

Classification

DUA Comments

1 DSA

- COMMON DATA TYPES -

ServiceControIs

options o s

priority O s

time Limit O s

sizeLimit 0 s

scopeUiKeierrai O s

EntrylnformationSelection

attributeTypes o S

allAttributes o s Must support at least one of the CHOICE.

select o s

r rp mio 1 ypes o s

Entrylnformation

DistinguishedName S M

fromEntry S G

SET OF CHOICE S G

AttributeType S G

Attribute S G

Filter Must support at least one of the CHOICE.

item 0 S

and 0 s

or 0 s

not o s

Filterltem

equality 0 s

substrings o s

type M s

strings M s

initial o s Must support at least one of the CHOICE.

any o s

final o s

greaterOr Equal o s lessOrEqual o s

present 0 s approximateMatch 0 s

11 - 46
December '89

Table 11.3. DAP Protocol Support (Part 7 of 7)

Protocol Element

Support

Classification

DUA DSA Comments

SecurityParameters O O See Section 11.8.8. certification-path O S name 0 S

time O S

random o b

target o S

ContinuationReference

targetObject o M

aliasedRDNs 0 G

OperationProgress o M

nameResolutionPhase o M

nextRDNToBeResolved 0 G

rdnsResolved o G

AccessPoint 0 M

AccessPoint

Name o M

Preser tationAddress 0 M

pSelector o G

sSelector 0 G

tSelector o G

nAddress o M

Notes for table 11.3

1 . As performance of Search and List operations can consume significant resources, the

policies of some centralized DSAs may be that such operations will not be performed.

For these cases, the reply to the requests for such operations would be ServiceError

with the "unwillingToPerform" Service Problem.

2. See EntrylnformationSelection information under Common Data Types (table 11.3, part 6)

11-47
December '89

Table 11.4. Directory System Service Support.

Operations and Errors

Support

Classification

Request Response Comments

- RTND and IINRIND -

DSABind n (notes 1,2) r DSAUnbind n (notes 1,2) r

- OPERATIONS -

- CHAINED READ OPERATIONS - ChainedRead n (notes 1,2) r ChainedCompare n (notes 1,2) r chainedAbandon n (note 1) r

- CHAINED SEARCH OPERATIONS - ChainedList n (note 1) r ChainedSearch n (note 1) r

- CHAINED MODIFY OPERATIONS - ChainedAddEntry n (note 1) r ChainedRernoveEntry n (note 1) r ChainedEntry n (note 1) r ChainedModifyRDN n (note 1) r

- ERRORS - Abandoned n (note 1) r Abandonfailed n (note 1) r AttributeError n (note 1) r NameError n (note 1) r DSAReflferal n (note 1) r SecurityError n (note 1) r SeviceError n (note 1) r UpdateError n (note 1) r

Notes for table 11.4

1. Necessary when supporting the chained mode of interaction.

2. Some of these operations may be necessary to support distributed authentication. This requirement is distinct from support for chained mode of interaction.

11-48
December '89

Table 11.5. DSP Protocol Support (Part 1 of 9)

Protocol Element

Support

Classification

Request Response Comments

- BIND and UNBIND -

DSABind

DirectoryBindArgument M S

credentials G S

simple G S name G S

validity 0 o

password G s strong O o See Strong Authentication Protocol Conformance Profile

for requirements when strong authentication is supported.

externalProcedure 0 0

versions G s Supported value; vl988 DSABindResult S G

credentials S G Shall be the same CHOICE as in DirectoryBindArgument.

simple S G

name S G

validity 0 O

password S G

strong o O See Strong Authentication Protocol Conformance Profile

for requirements when strong authentication is supported.

externalProcedure o O

versions S G Supported value: vl988

DirectoryBindError S G

versions S G Supported value: vl988

ServiceProblem S G Supported values: busy and unavailable. SecurityProblem s G Supported values: inappropriateAuthentication, invalid- Credentials.

DSAUnbind The DSAUnbind has no argvunents.

11 - 49
December '89

Table 11.5. DSP Protocol Support (Part 2 of 9)

Support

Classification Request Response (lommpn All 1^11 tLOq

- OPERATIC)NS, ARC JMENTS AND RESULTS -

- CHAINED READ OPERATIONS -

1 1 cL1 1 1 C U, JXC a.U,

v_^ii<iiuiiig/\.rguin.enii M S

IVCclU/\rgUlllCll L M S

object M

selection Kj c c\j oo

(! 1 i CLin11 1 1in1 1 trRpQiilf X O U. 1

L

c M

JXCclU XVCo U1

1

s M

^^n t TV s M

CommonResults s G

ChainedCompare

v^iidllilllt/^l t Uilicii L M S

CompareArgument M S

object M S

purported M s CommonArguments G s

ChainingResult S M

CompareResult s M

DistinguishedName s G

matched s M

fromEntry s G

CommonResults s G

ChainedAbandon

AbandonArgument M S

invokeld M S

AbandonResult s G

{

11 - 50
December '89

Table 11.5. DSP Protocol Support (Part 3 of 9)

Protocol Element

Support

Classification

Request Response Comments

- OPERATIONS, ARGUMENTS AND RESULTS -

- CHAINED SEARCH OPERATIONS -

ChainedList

ChainingArguments M S

ListArgument M S

object M S

CommonArguments G S

ChainingResults S M

ListResult S M

listlnfo S G

DistinguishedName S G

subordinates S M

Rel. DistinguishedName S M

aliasEntry s G

fromEntry s G

partialOutcomeQualifier s G

CommonResults s G

uncorrelatedListlnfo s G

ListResult s G

ChainedSearch

SearchArgument M S

baseObject M s

sugset G s

filter G s

searchAliases G s

selection G s CommonArguments G s

ChainingResults S M

SearchResult S M

Searchinfo s M

DistinguishedName s G

entries s M

partialOutcomeQualifier s G

CommonResults S G

uncorrelatedSearchinfo s G

SearchResult s G

partialOutcomeQualifier S G

limitProblem s G

unexplored S G

unavailableCriticalExt s G

11 - 51
December '89

Table 11.5. DSP Protocol Support (Part 4 of 9)

Protocol Element

Support

Classification

Request Response Comments

- <^nAlINryU MUUIJ:' Y vJrhiRAilUJNb - UnameuAaatintry

ChainingArguments M S

AddEntryArgument M S

object M S

entry M S

CommonArguments G S

UnamingKesults S M

AddEntryResults S M

C/hainedKemoveEntry

C/hammgArguments M S

RemoveEntryArgument M S

object M S

CommonArguments G s

ChainingResults S M

RemoveEntryResult s M

ChainedModifyEntry

ChainingArguments M s ModifyEntryArgument M s

object M s

changes M s addAttnbute G s

removeAttribute G s addValues G s removeValues G s CommonArguments ri co

ChainingResults S M

ModifyEntryResult S M

ChainedModifyRDN

ChainingArguments M s ModifyRDNArgument M s

object M s newRDN M s deleteOldRDN G s CommonArguments G s

ChainingResults S M

ModifyRDNResult S M

11 -52
December '89

Table 11.5. DSP Protocol Support (Part 5 of 9)

Protocol Element

Support

Classification

R PQrion QP Comments

- ERRORS and PARAMETERS - Abandoned

AbandonFailed

problem S M

operation s M

AttributeError Min. 1 error (see Directory Documents, part3, clause 12.4.2.2) object s M

problems s M

problem s M

type s M

value s G

NameError

problem s M

matched s M

DSARefFeral

ContinuationReference s M

contextPrefix s G

SecurityError

problem s M

11 - 53
December '89

Table 11.5. DSP Protocol Support (Part 6 of 9)

Protocol Element

Support

Classification Request Response Comments

cS M

Update Error s G

problem s M

- COMMON ARGUMENTS / RESULTS -

CommonArguments

ServiceControls G S

SecurityParameters 0 S see Section 11.8.8. requestor G S

OperationProgress G s nameResolutionPhase M s nextRDNToBeResolved G s aliasedRDNs G s

extensions G s

identifier M s

critical G s

item M s

ConrunonResults

SecurityParameters S o See Section 11.8.8. requestor s G

aliasDereferenced s G

11-54
December '89

Table 11.5. DSP Protocol Support (Part 7 of 9)

Protocol Element

Support

Classification

Request Response Comments

- COMMON DATA TYPES -

ServiceControls

options G S

priority G S

timeLimit G S

sizeLimit G S

scopeOfReferral G S

EntrylnformationSelection

attributeTypes G S

allAttributes G s

select G s infoTypes G s

Entrylnformation

DistinguishedName S M

fromEntry S G

SET OF CHOICE S G

AttributeType s G

Attribute s G

Filter item G S

and G S

or G S not G s

Filterltem

equality G s

substrings G s type G s

strings G s

initial G s any G s

final G s greaterOrEqual G s

lessOrEqual G s

present G s approximateMatch G s

11 - 55
December '89

Table 11.5. DSP Protocol Support (Part 8 of 9)

Protocol Element

Support

Classification

Request Response Comments

- COMMOlN JJAiA i DISTRIBUTED OPERATION -

originator G S

targetObject G S

oper ation Progress G s nameResolutionPhase M s nextRDNToBeResolved G s

tracelnformation M s

aliasDereferenced G s aliasedRDNs G s returnCrossRefs G s See Directory Documents, Part 4, clause 10.4.1 referenceType G s Domainlnfo o 0

timeLimit G s

SecurityParameters 0 s See note 1 tnaffe 11 — .^Tl ree^arninp" tlip Qiinnnrt

sification for Request. Also see Section 11.8.8

ChainingResults

Info O o

crossReferences c G

SecurityParameters S o See note 1 (page 11-57) regarding the support clas- sification for Response. Also see Section 11.8.8

Cross Reference

contextPrefix S M See Directory Documents, Part 4, clause 12.4.2.2 accessPoint S M

Tracelnformation

Traceltem M s

Traceltem

dsa M s

targetObject G s

operationProgress M s nameResolutionPhase M s nextRDNToBeResolved G s

11 -56
December '89

Table 11.5. DSP Protocol Support (Part 9 of 9)

Protocol Element

Support

Classification

Request Response Comments

ContinuationReference

targetObject S M

aliasedRDNs S G

operationProgress S M

nameResolutionPhase S M

nextRDNToBeResolved S G

rdnsResolved S G

referenceType S G

AccessPoint S M

AccessPoint

Name S M

PresentationAddress s M

pSelector s G

sSelector s G

tSelector s G

nAddress s M

Notes for table 11.5

1. The support classification is G when supporting the chained mode of interaction.

2. Some of these operations may be necessary to support distributed authentication.

This requirement is distinct from support for chained mode of interaction.

11 -57
December '89

Table 11.6. DAP Support for Digital Signature Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

- COMMON ARGUMENTS / RESULTS - CommonArguments

SecurityParameters

certification-path G S name G S

time G S

random G S

target G S

requestor G S

CormnonResults

Security Parameters S G

performer S G

Table 11.7. DSP Support for Digital Signature Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

- COMMON ARGUMENTS / RESULTS - CommonArguments

Security Parameters

certification-path G S name G S

time G S

random G S

target G S

requestor G S

CommonResults

SecurityParameters G s performer 0 G

11 - 58
December '89

Table 11.8. T~)AP Support for Strong Authentication Protocol Conformance Profile.

Protocol Element

Support

Classification

DUA DSA Comments

DirectoryBindArgument M s

credentials G S

simple G S name G S

validity G s password G s strong

certification-path G s

bind-token G s

externalProcedure 0 o

versions O s

DirectoryBind Result S G

credentials S G

simple s G

name s G

vahdity s G

password s G

strong s G

certification-path s G

bind-token s G

externalProcedure 0 O

versions s 0

11 - 59
December '89

Table 11.9. DSP Support for Strong Authentication Protocol Conformance Profile.

Protocol Element

Support

Classification DUA DSA Comments

DirectoryBindArgument M s

J i. * 1 credentials /-I simple G s G S

validity G S

password G S

strong

certification-path G S

bind-token G s externalProcedure 0 o

versions 0 S

DirectoryBindResult S G

credentials S G

simple S G

name s G

validity s G

password s G

strong s G

certification-path s G

bind-token s G

externalProcedure 0 O

versions s O

11 - 60
September 1990 (Stable)

Table 11.10. Error Symptoms (Part 1 of 3)

Symptom Descriptor!

E_ACCESS The initiator has insufficient access rights to carry out this operation.

E_ADMIN_LIMIT The Directory heis reached some Umit set by an administrative authority,

and no partial results are available to return to the user. E_ALIAS_DEREF One of three situations exists:

1. An alias has been encountered while a previous alias was being deref- erenced, or

2. a name contained an alieis plus one or more additional RDNs when

the dontDereferenceAliases service control was being used, or

3. the name, supphed in an operation that precludes alias dereferencing,^

contained an alias plus one or more additional RDNs.

**

E-ALIAS-LOOP During a whole-subtree search operation, an alias has been encountered

which would lead to a loop (i.e., the alias points to an entry which is superior to entries which have already been evaluated in earring out the

search).

E_ALIAS_PROBLEM An aUas has been encountered, but the entry to which it points does not

exist. E_ARG_BOUNDS The argument does not comply with pragmatic constraints (defined locally or by functional standards).

E_ARG^YNTAX An operation argument either has incorrect ASN.l encoding or it has correct ASN.l encoding, but does not comply to the syntax as defined in the

Directory Documents. Note:

1. Within BindArgument, additional elements are permitted, to allow

future extensions, and do not create an error situation.

2. Errors within attribute values are not included in this codification

(see E_ATT^YNTAX).

E_ARG_VIOL An operation argument has correct syntax, but it violates additional rules and constraints levied by the Directory Documents (e.g., use of a Priority

integer value whose meaning is undefined). Note:

1. Within a Relative Distinguished Name, having two AVAs of the same

attribute type is an error which is covered by E_DN, and not by

EJ\.RG-VIOL.

2. Errors within attribute values are not included in this codification

(see E-ATT^YNTAX).

E_ATT_BOUNDS An attribute value does not comply with bounds specified either by the

Directory Documents or by functional standards.

E-ATT.OR.VALUE_EXISTS Within an entry, an attribute or attribute value already exists, causing an

error situation.

11 -61
September 1990 (Stable)

Table 11.10. Error Symptoms (Part 2 of 3)

Symptom Descriptor!

EJVTT^YNTAX An attribute value either has incorrect ASN.l encoding or it has correct ASN.l encoding but does not comply witht the ASN.l encoding defined by

the attribute type.

EJITT.VALUE An attribute value, although of correct ASN.l encoding, and conformant

with the syntax defined for the attribute type, is not compliant with other

rules (e.g., a non-ISO 3166 country name encoding).

E_ACCESS The initiator has insufficient access rights to carry out this operation.

EJ\.UTHENTICATI0N The authentication offered does not match that required by the object being

authenticated.

E3USY The DSA is unable to handle this operation at this time (but it may be

able to do so after a short while).

E.CHAIN The DSA needs to use chaining to carry out this operation, but is prohibited

from doing so by Service Controls.

E-CREDENTIALS The credentials offered do not match those of the object with which au- thentication is taking place.

EJDBE An inconsistency has been detected in the DSA's data base, which may be

localized to a particular entry or set of entries. EJDIT-STRUCTURE An attempt was made via an add operation to to place an entry in the DIB

whose object class would violate the DIT structure rules. EJDN A DN contains an RDN with two AVAs of the same attribute type.

E_DSA A DSA to which chaining is taking place is unable to respond.

ej;ntry_exists An entry of the given name already exists, causing an error. E_EXTENSION A DSA was unable to satisfy a request because one or more critical extensions were not available. ejllegal_root.obj Root's DN hcis been supplied as the object of a Read, Compare, AddEntry,

RemoveEntry, ModifyEntry, ModifyRDN, or as the Base Object of a smgie

ICVCl oCalCll. EJLLEGAL_ROOT.VAL Root's DN has been supplied illegally as an attribute value (e.g., as an

Aliased Object Name).

EJLOOP A loop has been detected in the knowledge information within the system.

E_MATCH ine attribute specified does not support the required matching capability.

E_MISSING_AVA When creating, or after modifying, an entry, an AVA in the entry's RDN

is not represented within the entry's set of attributes. E_MISSING.OBJECT-CLASS When creating an entry, the entry does not possess an object class. E_MULTI_DSA The operation is an update operation which affects other DSAs.

E_NAMING.VIOLATION The name of the new or modified entry is incompatible with its object class. E_NONXEAF.OPERATION The operation being attempted is illegal except on a leaf. EJ^JONNAMINGjVTTRIBUTE In either an add or ModifyRDN operation, an attribute is included in the

last RDN that is not a valid naming attribute according to the DIT struc- ture rules.

11 - 62
September 1990 (Stable)

Table 11.10. Error Symptoms (Part 3 of 3) Symptom Descripton

E3rOT.SINGLE.VALUED An attribute, registered as single-valued, has been found with more than one value. EJ^O..SUCH_ATT The specified attribute has not been found.

E_NOjSUCH.OBJECT The specified entry has not been found.

EJ^O^UCH.VALUE The specified attribute value has not been found.

E.OBJECT.CLASS_MOD An (illegal) attempt has been made to alter or remove an object class attribute.

E-OBJECT_CLASS_VIOL There is a schema violation (e.g., missing mandatory attribute, or nonallowed attribute present).

E_REFERENCE An erroneous reference has been detected (e.g., DSA cannot handle name

even as far as the number of RDNs that have already been resolved).

E-SCOPE No referrals were available within the requested scope. E.SYSTEM_PERM A serious and permanent software or system error has been detected which

prevents completion of the operation.

E_SYSTEM_TEMP A serious but temporary software or system error has been detected which

prevents completion of the operation.

E.TIMEOUT The operation has not completed within the allotted time.

E.UNABLE_TO.COMPLETE The DSA is unable to complete this operation, or others like it (this applies

particularly to search).

E.UNABLE_TO_PROCEED The DSA cannot satisfy the operation after receiving it on the basis of a

valid non-specific subordinate reference. E_UNDEFINED_ATT An unregistered attribute has been encountered.

E.UNSUPPORTED.OC The object class of the entry is not supported as a valid object class for entries within this DSA.

E-VERSION An unexpected version has been found in Bind.

E.ZERO.VALUES An attribute has been found (e.g., as a result of a modify-entry operation)

with no values.

11 - 63
September 1990 (Stable)

Table 11.11. Error Situations

Situation Description

RTND XJi.il LJ- TLj or* wV_y >VATLj A hinH i<? Kpinp^ attemnted* either the entrv named is for should be)

within a local naming context, or name resolution is being carried out on the part of the name that is known locally.

BIND-REMOTE A bind is being attempted, and the entry named is not within a local naming context; remote validation of credentials is being

carried out. NAME-RESOLUTION Name resolution is being carried out. ADD-ENTRY-NAME-RESOLUTION During an add entry operation, name resolution has been successfully accomplished on the superior object, and is not being carried out to determine whether the new entry already exists. ADD-ENTRY The entry is being generated.

MODIFY-ENTRY The entry is being modified.

MODIFY-RDN The RDN is being modified.

REMOVE-ENTRY The entry is being removed.

READ The entry is being read. COMPARE A Compare operation is being carried out on the entry.

LIST A List operation is being carried out on the entry.

SEARCH-FILTER A Search operation is being carried out; the filter is being evaluated

or acted upon.

SEARCH-ENTRY A Search operation is being carried out; the required entry infor- mation is being evaluated or acted upon.

ABANDON An Abandon operation is being carried out. TRACE-EVALUATION The trace element is being evaluated for loops.

11 - 64
September 1990 (Stable)

Table 11.12. Notation Used to Describe Error Actions

Error Action

Notation Meaning

Rej A reject operation is generated, with problem mistyped-argument.

Ah[< qualifier>) Abandon Failed Error is generated. The qualifier may take on values codified as

follows: CA — Cannot abandon

TL - Too late NSO - No such operation

A{< qualifier>) Attribute Error is generated. The qualifier ma,y take on values codified as follows: AVE - Attribute or value already exists IAS — Invalid attribute syntax

NSA - No such attribute

CV - Constraint violation IM - Inappropriate matching

UAT - Undefined attribute type

'N{<qualifier>) NameError is generated. The qualifier may take on values codified as follows: ADP - Alias dereferencing problem

IAS - Invalid attribute syntax

AP - Alias problem

NSO - No such object

SC{< qualifier>) Security Error is generated. The qualifier may take on values codified as follows:

lA - Inappropriate authentication

IC - Invalid credentials NI - No information

lAR — Insufficient access rights IS - Invalid signature

PR - Protection required

S{<qualifier>] Service Error is generated. The qualifier may take on values codified as follows: ALE - Administrative limit exceeded B Busy

CR - Chaining required DE - Dit Error IR - Invalid reference LD - Loop detected COS - Out of Scope TLE - Time limit exceeded

UA - Unavailable UAP - Unable to proceed

UCE - Unavailable critical extension UWP - Unwilling to perform

\J {< qualifier>) Update Error is generated. The qualifier Taa.y take on values codified as follows: AMD - Affects multiple DSA EAE - Entry already exist NAN - Not allowed on non-leaf NAR - Not allowed on RDN

NV - Naming violation OCV - Object class violation OMP - Object class modification prohibited

11 - 65
September 1990 (Stable)

Table 11.13. Error Actions (Part 1 of 6)

Situation (See Table 11.11)

Symptom Bind- Add-Entry-

(See Table 11.10) Bind- Remote- Name- NameLocal Resolution Resolution Resolution Add-Entry Modaiy-nntry

B_A.CCESS SC(IAR)(14) SC(IAR)(14) SC(IAK)(14) SO(iARj(14)

E_ADMlNJjlMi i S(UA) S(UA) S(ALE) S(ALE) O / AT C»\

A T T A C TM7*'D"C^T S(IC) S(IC) N(ADP)

I? ATTAC J r\C\X> Ci _AJj iAo_1j UU

b-A. LlAS_r KOBLh^M S(IC) S(IC) N(AP)

_AKO-D U U JN Uo (8) b^U Wr^^1^ ) (1) (1) Rej Rej Rej Rej

E-ARG.VIOL (1) (1) Rej Rej Rej Rej

EJ^TT30UNDS SC(IC) (7) N(IAS) N(IAS) A(CV) A(CV)

E_A.TT.OR-VALUEj;XISTS A(AVE) A(AVE)

EJVTT^YNTAX SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

EJ^TT.VALUE SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

EJ^UTHENTICATION SC(IA) SC(IA)

E3USY S(UA) S(UA) S(B) S(B) S(B) S(B)

E-CHAIN S(CR)

E.CREDENTIALS SC(IC) SC(IC)

EJDBE S(UA) S(UA) S(DE) S(DE) S(DE) S(DE)

EJJITJSTRUCTURE U(NV)

EJ)N SC(IC) SC(IC) N(NSO) C(NV)

E_DSA S(UA) S(UA) S(UA)

EJENTRYJ:XISTS U(EAE)

E-EXTENSION S(UWP) S(UCE) S(UCE) S(UCE)

EJLLEGALJIOOT-OBJ SC(IC) SC(IC) N(NSO) N(NSO) N(NSO)

EJLLEGALJIOOT-VAL SC(IC) (7) N(IAS) N(IAS) A(IAS) A(IAS)

E_LOOP S(UA) S(LD)

11 - 66
September 1990 (Stable)

Table 11.13. Error Actions (Part 2 of 6)

Situation (See Table 11.11)

Symptom Bind- Add-Entry-

(See Table 11.10) Bind- Remote- Name- NameLocal Resolution Resolution Resolution Add-Entry Modify-Entry

E^ATCH SC(IC) SC(IC) A(IM) A(IM) A(IM)

E.MISSING_AVA U(NAR) U(NAR)

EJ^ISSING.OBJECT-CLASS U(OCV) U(OMP)

EJklULTLDSA S(AMD)

E_NAMING-VIOLATION U(NV)

E_NON.LEAF.OPERATION

E_NONNAMING.ATTRIBUTE U(NV)

E_NOT.SINGLE.VALUED A(CV) A(CV)

EJJfO-SUCH.ATT A(NSA)

EJ^O-SUCH-OBJECT SC(IC) SC(IC) N(NSO)

E-NO-SUCH.VALUE A(NSA)

E.OBJECT.CLASSJvIOD U(OMP)

E.OBJECT.CLASS.VIOL U(OCV) U(OCV)

EJIEFERENCE S(UA) S(IR)

E^COPE S(OOS)

E^YSTEMJ'ERM S(UA) S(UWP) S(UWP) S(UWP) S(UWP)

EJSYSTEM.TEMP S(UA) S(UA) S(UA) S(UA) S(UA)

E.TIMEOUT S(UA) (9) S(TLE) S(TLE) S(TLE) S(TLE)

E.UNABLE.TO.COMPLETE

E.UNABLE.TOJ'ROCEED (2) (2) E.UNDEFINED_A.TT SC(IC) (3) U(NV) A(UAT) A(UAT)

E.UNSUPPORTED-OC U(OCV)

E.VERSION S(UA)

EJERO-VALUES A(CV) A(CV)

11 - 67
September 1990 (Stable)

Table 11.13. Error Actions (Part 3 of 6)

^vmFit nm

(See Table 11 101

Situation (See Table 11.11)

RDN

IVCIIIUVC— Entry Read Compare

Trace- Evaluation

E_A.CCESS SC(IAR)(14) SC(IAR)(14) SC(IAR)(14)

E_A,DMINJL,IMIT S(ALE) S(ALE)

E_A.LIAS_DEREF

E_A.LIASJjOOP

E_A.LIAS-PROBLEM

E-ARG^OUNDS S(UWP)(12) S(UWP)(12)

EJ^RGJSYNTAX Rej Rej Rej

EJ\.RG.VIOL Rej Rej Rej Rej

E-ATT-BOUNDS N(IAS) A(CV) (7) E-ATT.OR.VALUE.EXISTS

EJ^TTJSYNTAX N(IAS) A(IAS) (7) E-ATT.VALUE N{IAS) A(IAS) (7) E_A.UTHENTICATION

E_BUSY S(B) S(B) S(B) S(B)

E.CHAIN

E.CREDENTIALS

EJ)BE S(DE) S(DE) S(DE) S(DE)

EJ5ITJSTRUCTURE

EJDN A(CV) A(IAS)

EJDSA

E^NTRY.EXISTS U(EAE)

E_EXTENSION S(UCE) S(UCE) S(UCE) S(UCE)

EJLLEGALJIOOT-OBJ N(NSO) N(NSO) N(NSO) N(NSO)

EJLLEGAL-ROOT-VAL N(IAS) A(IAS) (7) E-LOOP

11 - 68
September 1990 (Stable)

Table 11.13. Error Actions (Part 4 of 6)

Symptom

(See lable 11.10)

Situation (See Table 11.11)

ModifyRDNRemoveEntry Read Compare

Trace- Evaluation

E_MATCH A(IM) A(IM) (7) E-MISSIN G-A.VA

E_MISSING_OBJECT_CLASS

E_MULTI_DSA S(AMD) S(AMD)

EJnAMING-VIOLATION U(NV)

E_NON-LEAF-OPERATION T T/XT A XT \ U(N AN) T T / XT A XT\ U(N AN)

E_NCT-SINGLE.VALUED A(CV)

E-NO-SUCH-ATT A(NSA)(4) A(NSA)(4)

E_NO.SUCH.OBJECT

EJ^O.SUCH.VALUE

E-OBJECT-CLASSJVIOD

E.OBJECT.CLASS.VIOL U(OCV)

EJIEFERENCE

EJSCOPE

E^YSTEMJERM S(UWP) S(UWP) S(UWP) S(UWP) S(UWP)

E^YSTEM.TEMP S(UA) S(UA) S(UA) S(UA) S(UA)

E.TIMEOUT S(TLE) S(TLE) S(TLE) S(TLE)

E.UNABLE.TO.COMPLETE

E.UNABLE.TO.PRCCEED

E.UNDEFINED.ATT A(UAT) A{NSA)(4) A(NSA) (7) E.UNSUPPORTED-OC

E-VERSION

EJZERO.VALUES (11)

11 - 69
September 1990 (Stable)

Table 11.13. Error Actions (Part 5 of 6)

Situation (See Table 11.11)

Symptom

(See Table 11.10) List Search Seeirch

(Filter) (Filter) Entry Abandon

EJVCCESS SC(IAR)(14) SC(IAR)(14) SC(IAR)(14)

E^DMINXIMIT S(ALE)(13) S(ALE)(13) S(ALE)(13)

E_A.LIASJDEREF (5) E_ALIAS_LOOP (5) EJ^LIAS_PROBLEM (5) EJ^.RG^OUNDS S(UWP)(12) S(UWP)(12) S(UWP)(12)

EJVRG^YNTAX Rej Rej Rej Rej

E-ARG.VIOL Rej Rej

E-ATTJ30UNDS A(CV)

E_ATT-OR.VALUE-EXISTS

EJiiTT-SYNTAX A(IAS)

EJ^TT.VALUE A(IAS)

E_AUTHENTICATION

E_BUSY S(B) S(B) S(B)

E.CHAIN

E.CREDENTIALS

EJDBE S(DE) S(DE) S(DE)

E_DIT.STRUCTURE

EJDN A(IAS)

EJDSA (5) EJ}NTRY.EX1STS

ej:xtension S(UCE)(13) S(UCE)(13) S(UCE)(13)

EJLLEGAL_ROOT.OBJ (10) EJ[LLEGAL_ROOT-VAL A(IAS)

EXOOP (5)

11 - 70
September 1990 (Stable)

Table 11.13. Error Actions (Part 6 of 6)

Symptom

(See Table 11.10)

Situation (See Table 11.11)

List

(Filter)

Search

(Filter)

Search Entry Abandon

EJ^ATCH A(IM)

EJvIISSINGJVVA

EJvIISSING-OBJECTXLASS

E_MULTI_DSA

E_NAMING.VIOLATION

E_NON-LEAF.OPERATION

E_NONNAMING-ATTRraUTE

E_NOT-SINGLE.VALUED

E_NO.SUCH.ATT

EJ40.SUCH.0BJECT

EJ40.SUCH-VALUE

E.OBJECT.CLASS_M0D

E.OBJECT-CLASS-VIOL

EJIEFERENCE

E.SCOPE

EJSYSTEM.PERM S(UWP) S(UWP) S(UWP) Ab(CA)

E.SYSTEM.TEMP S(UA) S(UA) S(UA) Ab(CA)

E.TIMEOUT S(TLE)(13) S(TLE)(13) S(TLE)(13)

E.UNABLE.TO.COMPLETE S(B) S(B) S(B) Ab(CA)

E.UNABLE.TO.PROCEED

E.UNDEFINED.ATT (6) (6) E.UNSUPPORTED-OC

E.VERSION

E.ZERO-VALUES

11 - 71

vj tj w vyvz-i
September 1990 (Stable)

Notes for table 11.13

1. Use A-U-ABORT. Note, however, that extra elements are permitted here.

2. An "unable-to-proceed" error becomes SC(IC) for bind and N(NSO) for operations

if no DSA contacted can located the object.

3. An undefined attributed encountered during name resolution is ordy an error - N(NSO) - if the entry is identified as local. See also Note 10 below.

4. The A(NSA) condition is reserved in the case of "read" for the situation when no

attribute of the specific list provided can be returned (for re<isons that include security

errors).

5. Any fsdlure to propagate a search causes abandonment of that part of the search.

6. Undefined attributes are regarded as not matched or found, but cause no errors in search.

7. This error, if detected, should be ignored; processing continues.

8. This error would occur as a result of a bind argument with a name containing too many RDNs for the DSA. Use either S(UA) or S(IC).

9. DSAs should use the time-limit service control with local timeout to limit the remote

validation of credentials; if the operation fails as a result, S(UA) is used.

10. For a single-entry search, N(NSO) may be used.

11. Either the whole attribute should be removed, or the deleteOldRDNflag should be

ignored.

12. Wherever S(UWP) appears in the above tables beside E_ARG_BOUNDS, a ROSE

"Rej" is also admissible.

13. The error is returned when there are no partial results, otherwise a partialOutcomeQualifier with the appropriate limitProblem is returned (cf Directory Documents, Part

3, item g of clause 12.8.2, and Part 3, clause 10.1.3.3.1).

14. In every case where a security error occurs, except in bind, SC(NI) may be used

in place of the specified problem, to support a Security Policy which states that no

information on the problem may be divulged. In the case of the bind, SC(NI) is not

available.

11 - 72
December '89

12. SECURITY

The Security Architecture specified in ISO 7498/Part 2 - Security

Architecture (as presented in ISO/TC 97/SC 21/N1528) shall be used as a basis for further work in the Special Interest Group on Security.

The security services that are to be implemented first shall include

confidentiality, integrity, authentication and access control. Nonrepudiation of the source shall also be included for consideration for

implementation. These services are defined and discussed in more detail

in ISO 7498/Part 2 - Security Architecture.

12 . 1 Definitions

The following definitions, based on the definitions in ISO 7498/Part

2, are to be used when interpreting chapter 12.

Access Control: The provision of a security system

that establishes and enforces which

users or processes can get access

to what data or processing

facilities

.

Authentication

Information: Information used to establish the

validity of a claimed identity.

Authorization:

Confidentiality:

The granting of access rights.

A security service that protects

data from unauthorized disclosure.

Connection: A state of communication that

exists between two communicating

entities by establishing an association between them, providing

one or more data paths between them

allowing sequential transfers of

data, and then terminating the

association

.

Connectionless

:

A state of communication that

provides transfer of data from one entity to another without a preestablished association.

Data Integrity: The property that data has not been

altered or destroyed in an unauthorized manner.

12-1
December '89

Data Origin

Authentication: The corroboration that the source of data received is as claimed.

Digital Signature;

Peer-entity

Authentication:

Data that allows a recipient of

information to verify the source and integrity of the information.

The corroboration that peer

entities in an association are as claimed.

Repudiation: Denial by one or both of the

entities of an association of

having participated in all or part

of the association or communication of the association.

Selective Field

Protection: The protection of specified fields

of data in a communication.

Traffic Analysis

Traffic Flow

Confidentiality:

The inference of information from

observation of traffic flow in

communications (presence, absence,

amount, direction and frequency).

A confidentiality service to

protect against traffic analysis.

12 . 2 Matrix of Security Services and OSI Layers

The following matrix shows the layers of the OSI architecture at which

certain security services are considered to be desirable. The entries

in the matrix are "H" for high level of desirability, "M" for medium

desirability, and "L" for low level of desirability. No entry in the

matrix means that the service is not considered desirable. This

matrix was produced from a similar matrix in ISO 7498/Part 2 which

showed the layers of the architecture that could be used to provide

the security service. The level of desirability was established by

the members of the Special Interest Group in Security of the OSI

Implementors Workshop.

Note: The Matrix is a consensus of the opinions of the members as to

where selected security services should be placed. It should not be

12-2
December '89

considered restrictive and interpreted as meaning that the security

services cannot be placed elsewhere in the OSI architecture or have

other implementation priorities. This will depend upon the differing

security needs of specific applications. Also, it should not be

considered complete in that other security services may exist that

should be incorporated in the architecture.

Table 12.1. OSI Layers Desirable for Placing Security

SERVICE 1 2 3 4 5 6 7

1 (a) Peer entity authentication L H H (b) Data origin authentication L L H

2 Access Control Service

M M H

3 (a) Connection confidentiality L L L H H H

(b) Connectionless confidentiality L H L H H (c) Selective field confidentiality H H

(d) Traffic flow confidentiality M L L

4 (a) Connection integrity with recovery H L

(b) Connection integrity without recovery N N N (c) Selective field connection integrity N

(d) Connectionless integrity H L L

(e) Selective field connectionless integrity H

5 (a) Non-repudiation: originator L

(b) Non-repudiation: receiver L

Implementation priority: H (high)

M (medium)

L (Low)

N (No Priority)

Table 1. ISO 7498/Part 2: Security Addendum -- NIST/OSI Workshop

Summary Of SIG-SEC Discussions of Security Service Placement, May,

1987

Notes: The following notes are for explanation of the above matrix and

comments

,

A security system should be considered to be an integrated set of

12-3
December '89

security services that are placed at selected OSI layers. The

services should be selected based on a risk analysis for the computer

system being protected. Security mechanisms must be then chosen that

will provide the security services and incorporated in the software

and hardware of the computer system and controlled by the OSI software

and hardware at the selected layer ( s)

.

For example, authentication, access control, confidentiality and

integrity are selected as the major security goals for an OSI system.

A connection oriented transport protocol is being implemented. An

example of the use of the Matrix could be in an electronic mail

system, to illustrate this the following specific services and layers were chosen:

Peer entity authentication: Layer 4

Data origin authentication: Layer 7

Access Control: Layer 7

Connection confidentiality: Layer 4

Selective field confidentiality: Layer 7

Connection integrity with recovery: Layer 4

Connectionless integrity: Layer 7

The layer 7 services were chosen to support the mail system that would

protect the selective paragraphs of an electronic message as directed

by the user. A mail system is considered connectionless. Access

control is a function of only layer 7.

The layer 4 services were chosen to provide a reliable transport

service from the sender to the intended receive of the electronic

message. A full connection integrity and confidentiality service with

peer entity authentication will assure that all information gets to

the receiver correctly and confidentially.

Note: The security protocols and mechanisms that provide these

services are beyond the scope of this chapter at this time. The

mechanisms and standards for their interoperability are presently

being defined and will be added to this chapter as they become

available

.

12-4
December '89

UL FUTURE SECURITY

Editor's Note: This section is reserved for future stable

Security Architecture Agreements. These

agreements may be found in the aligned section of

the Working Implementation Agreements Document.

When these agreements become stable, they will be

moved into this section 13 of this document.

Consult section 13 of the Working Agreements

Document for current information.

13-1
(iII
June 1990 Stable

14. ISO VIRTUAL TERMINAL PROTOCOL

14. 1 INTRODUCTION

The NIST/OSI Workshop Virtual Terminal (VT) SIG is making

implementation agreements for the OSI Basic Class VT Service and

Protocol, ISO 9040 and ISO 9041.

These implementation agreements fall into the following categories.

o Functionality to be implemented, i.e.,, functional units,

etc

.

o Identification and specification of VT profiles to be

supported by conforming implementations.

o Agreements with regard to implementation issues not

specified in ISO 9040 and ISO 9041.

o Resolution of problems with ISO 9040 and ISO 9041

identified during implementation.

o Statement of requirements to meet conformance to these

agreements

.

14.2 SCOPE AND FIELD OF APPLICATION

14. 2 . 1 Phase la Agreements

The Telnet profile is intended to support the following usage:

o a simple line at a time or character at a time

dialogue , and

o an application level gateway supporting Internet Telnet

and ISO VTP interoperation.

The Transparent profile supports the exchange of uninterpreted

sequences of characters. This includes support of VT-users who

wish to control terminals directly through the use of embedded

control characters and escape sequences.

14 . 2 2 Phase lb Agreements

The Forms profile is intended to support forms -based applications

with local entry and validation of data by the terminal system.

14-1
June 1990 Stable

This profile is now aligned with the EWOS VT EG Functional

Standard.

14 . 2 . 3 Phase II Agreements

The X.3 profile supports functionality similar to the CCITT

recommendations and could be used to implement an X.3 to ISO-VT

gateway.

See Working Agreements regarding Page profiles.

14.3 STATUS

14 . 3 .

1

Status of phase la

Phase la of the VT Agreements was stabilized May 5, 1988. This

phase covers the Telnet and Transparent profiles. No future

enhancements will be made to this phase.

14.3.2 Status of phase lb

Phase lb of the VT Agreements was first stabilized December 16,

1988. This phase covers the Forms profile. Alignment with EWOS

required substantial modifications which were ratified

September 15, 1989.

14 . 3 .

3

Status of phase II

Phase II is still in progress and includes the remaining profile

work for Scroll, Page (S-mode) and Page (A-mode) profiles.

The X.3 profile of phase II was stabilized December 15, 1989.

14.4 ERRATA

Editor's Note: "Defect Report" material may be included here,

including versions of implementor agrements to which it

applies

.

TECHNICAL

06/90-1 Forms Profile. The "FEICO Update Syntax" ASN.l comment

which follows the definition of the PriValue type was corrected to support multi-octet repertoires.

06/90-2 Forms Profile. The descriptive text for the Field

Entry Instruction Violation FEE was corrected to

14-2
September 1990 (Stable)

indicate that both an entry- control index and a FEPR

index are required to identify the FEPR concerned.

06/90-3 Forms Profile. The descriptive text and update syntax

for the Violation FEC were corrected to indicate that

both a FEICO-name and an index are required to identify

a FEIR.

06/90-4 Forms Profile. The update syntax for the writeString

FER was corrected to align with the descriptive text

for this FER.

06/90-5 Forms Profile. The descriptive text for the repertoire

assignment profile argument was corrected to properly

identify the default value as the GL set ISO 2375 Reg.

No. 6 (ASCII).

06/90-6 Forms Profile. The concept of a "current keystroke"

was inserted into the definition of the FEICO to remove ambiguity in the use of the ST and UT COs . Various

FEEs, FECs and FERs were redefined.

ALIGNMENT

06/90-7 Forms Profile. A definitive note was added to define

how the host is notified of the current entry location

when data entry terminates and the VTE-parameter

access-outside-fields has the value "allowed."

06/90-8 Forms Profile. Three font-assignment profile arguments

were added to accomodate INTAP requirements

.

09/90-1 Forms Profile. The emphasis subattribute "h" was added

with values "F" (Framed) and "C" (Encircled).

09/90-2 Telnet Profile. Four editorial comments were

incorporated to align with the corresponding EWOS

Functional Standard.

EDITORIAL

06/90-9 Forms Profile. Two definitive notes were added to

clarify the secondary attributes comparison mechanisms

for the FEIs and FECs that test equality of characters.

06/90-10 Forms Profile. A definitive note was added to clarify

the effect of associating multiple Character-oriented

FEIs of the same type with the same field.

14-3
September 1990 (Stable)

06/90-11 Forms Profile. An introductory paragraph in the

section "Field Entry Condition Definitions" was rewritten for clarification,

06/90-12 Forms Profile. The descriptive text for the Write

String field entry reaction was modified to indicate

precisely how and where the associated string is to be

written.

09/90-3 X3 Profile. The reference to COs P3 and P4 contained

in comments relating to DEVICE- 1 were corrected to

reference elements 3 and 4 of the PAD CO.

14.5 CONFORMANCE

Conformant VT implementations are required to support the ISO 9041

Clause 13 requirements plus the additional conformance requirements

identified below.

Figure 14.1 shows conformance status for VT facilities which are optional in the ISO VT standard. The terms used in the figure are defined as indicated below.

o "Mandatory" indicated the facility must be provided by all

implementations which conform to these agreements.

o "Optional" indicates that the VT facility is not required to

meet minimum conformance requirements but has been

identified as providing additional useful capabilities.

o "Profile Dependent" indicates that the requirement for the

facility, if any, is included in the profile definitions.

o "Not Addressed" indicates that the VT facility is outside

the scope of these agreements.

14-4
June 1990 Stable

Conformance Status Mandatory Optional Profile

Dependent

Not

Switch Profile ** X

Multiple Interaction

ii t; u i. d u X \j 11 ^ X

^ o ^ciccloti AY

UL^cllL. L/ctL-d YA

AY

AY

Ejiuiaiiceci riccess K-iixes ^

AY

AY

AY

Fields ** X

RIOs ** X

S-mode X

A-mode X

Mode Switching Capability X

Figure 14.1. Conformance Status for VT Facilities.

*It is not anticipated that new profiles will use quarantined delivery

control

.

Functional Units.

For each mode of operation (A-mode and S-mode) which is implemented,

the default profile for that mode as defined in ISO 9040 must be

supported. Implementations that support A-mode must support the Amode default profile and at least one additional Workshop approved Amode profile. The Transparent profile does not count as an additional

A-mode profile. Implementations that support S-mode must support the

14-5
June 1990 Stable

S-mode default profile and at least one additional Workshop approved

S-mode profile.

For each profile implemented, VTE parameter ranges or values specified

in the Workshop-agreed profile and associated notes must be supported.

14.6 PROTOCOL . >

14.6.1 Protocol Elements

All protocol elements required by the ISO 9040 VT kernel and

Break functional units are selected.

All protocol elements required by the Switch Profile functional

unit are selected if this functional unit is used. See figure

14.1.

All protocol elements required by the Urgent Data functional unit

are selected if this functional unit is used. See figure 14.1.

14.6.2 Mapping of Protocol Elements

Mapping of protocol elements on to ACSE or Presentation Seirvlces

is as defined in ISO 9041.

14.6.3 Protocol Data Unit Structure

Protocol data unit structure is as defined in ISO 9041.

14 . 7 OIW Registered Control Objects

The following Control Objects are used by more than one profile. Some

of the CO parameters are left with undefined values that must be

assigned by the profile in which the Control Object is used.

14.7.1 Sequenced Application (SA)

This is a Control object used to convey signals from the

application to the terminal in sequence with other updates.

14 7 1 1 Entry Number

To be supplied by Registration Authority.

14-6
June 1990 Stable

14.7.1,2 Name of Sponsoring Body

OSI Impleraentors' Workshop (OIW) , VTSIG.

14.7.1.3 Date

The date of submission of this proposal is September 15,

1989.

14. 7 . 1 .4 Identifier

oiw-vt-co-misc-sa OBJECT IDENTIFIER

{ oiw-vt-co-misc sa(0)

)

14.7.1.5 Descriptor Value

"OIW VT CO for conveying Sequenced Application Signals"

14 . 7 1 6 CO Parameters

CO-structure 1 CO-priority "normal"

CO-category "symbolic"

co-size 11

14 . 7 . 1 7 CO Values and Semantics

The following table lists the allowed symbolic values

together with the integers used to reference these values in

the ASN.l update syntax of ISO 9041:

audible_alarm 0

newlines_enabled 1 newlines_disabled 2

restore 3

visuai_alarm 4

keypad_enabled 5

keypad_disabled 6

keyboard_locked 7

keyboard_unlocked 8

device_disconnect 9

break_signal 10

14-7
June 1990 Stable

The semantics of each value must be specified in the VTE

profile which references this CO,

14.7.1.8 Additional Information

None

14.7.1.9 Usage

Defined in profile.

14.7.2 Unsequenced Application (Vk)

This is a Control object used to convey urgent signals from the

application to the terminal.

14. 7 . 2 1 Entry Number

To be supplied by Registration Authority.

14.7.2.2 Name of Sponsoring Body

OSI Implementors' Workshop (OIW) , VTSIG.

14.7.2.3 Date

The date of submission of this proposal is September 15,

1989.

14.7.2.4 Identifier

oiw-vt-co-misc-ua OBJECT IDENTIFIER: :=

{ oiw-vt-co-misc ua(l))

14.7.2.5 Descriptor Value

"OIW VT CO for conveying Unsequenced Application Signals"

14-8
June 1990 Stable

14.7.2.6 CO Parameters

CO- structure

CO-prlority

co-category

co-size

1"urgent"

"symbolic"

11

1^7. 2. 7 CO Values and Semantics

Same as in SA.

1^.7.2.9 Additional Information

None

.

14.7.2.? V?w

Defined in profile.

14.7.3 Sequenced Terminal (ST^

A keyboard can generate many signals that may be given special

meaning to the application. This CO is general enough to convey

any keyboard event.

14.7.3.1 Envry l^m^^i

To be supplied by Registration Authority.

14 . 7 3 . 2 Name of Sponsoring Body

OSI Implementors Workshop (OIW) , VTSIG.

The date of submission of this proposal is September 15,

14.7.3.? -Mis.

1989.

14-9
June 1990 Stable

14.7.3.4 Identifier

oiw-vt-co-misc-st OBJECT IDENTIFIER : := {oiw-vt-co-misc st(2)}

14.7.3.5 Descriptor Value

"OIW VT CO for conveying Sequenced Terminal Signals"

14.7.3.6 CO Parameters

CO -structure 1 co-priority "normal"

CO-category "integer"

co-size 65535

14.7.3.7 CO Values and Semantics

The values of the CO are composite, with values from table

below giving meaning to the values in the hex range 00-FF

when added to them,

hex value meaning

ICQ special key - labeled (see list)

200 function key depressed

400 control key depressed

800 shift key depressed

1000 alt key depressed

The special key and the function key are mutually exclusive.

If neither the function keys nor the special keys are pressed, then the value in the hex range 00-FF will be that

of the normal, unshifted code combination generated by the

alpha-numeric key. Values in the hex range 00-FF are not

valid values for the data element of this Control Object,

The control, shift, and alt keys may appear in any

combination with the special or function keys.

The shift key must occur in combination with at least one of

the other keys in the above table to cause the value to fall

outside the repertoire of the display object.

When the special key is depressed, the value of the CO

content will be as given in the ASN.l module below for the

14-10
June 1990 Stable

value in the hex range of 00-FF. Otherwise, the value will

be defined to be the IA5 value associated with the key.

STCO DEFINITIONS : := BEGIN

Key : := INTEGER {

break (0). bell (1), backspace (2),

tab (3). backlab (4), lineFeed (5),

carRe turn (6), cancel (7), substitute (8).

escape (9). plus (10), minus (11).

multiply (12), divide (13). leftArrow (14).

rightArrow (15), upArrow (16), downArrow (17).

insert (18), delete (19). insertLine (20).

deleteLine (21), home (22). end (23).

pageUp (24), PageDown (25). pal (26),

pa2 (27), pa3 (28), help (29) , statusProcess (30), interruptProcess (31), terminateProcess (32),

abortOutput (33), formFeed (34), clear (35),

print (36), refresh (37), systemRequest (38),

endOfRecord (39), endOfFile (40), suspendProcess (41)

-- Names for combination keystrokes are formed by converting the

-- initial letter to upper case and prefixing with 'Ctrl', 'shift' or

-- 'alt', which adds 1024, 2048 or 4096 respectively to the value.

-- These prefixes may be used in combination with one another by a

-- repetition of this conversion process, provided that they appear

-- from left to right in the order ' Ctrl', 'shift', 'alt'. ASN.l

-- formally does not allow such descriptive additions but it would be

-- very lengthy to write them all in full -- )

END *(STC0 DEFINITIONS)*

VTE profile definitions may refer to this module for

convenience in describing semantics.

14 . 7 . 3 .

8

Additional Information

None

.

14.7.3.9 Usa^e

Defined in profile.

14-11
June 1990 Stable

14.7.4 Unsequenced Terminal (UT)

Keyboard events may need to be conveyed urgently, out of sequence

with normal updates. This CO is used to signal such events from

the terminal to the application.

14.7.4.

1

Entry Number

To be supplied by the Registration Authority.

14.7.4.2 Name of Sponsoring Body

OSI Implementors Workshop (OIW) , VTSIG

14.7.4.3 Date

The date of submission of this proposal is September 15,

1989.

14.7.4.4 Identifier

oiw-vt-co-misc-ut OBJECT IDENTIFIER : := {oiw-vt-co-misc ut(3))

14.7.4.5 Descriptor Value

"OIW VT CO for conveying Unsequenced Terminal Signals"

14.7.4.6 CO Parameters

CO- structure 1 co-priority "urgent"

co-category "integer"

co-size 65535

14. 7 .4.

7

CO Values and Semantics

Same as in ST.

14-12
September 1990 (Stable)

14.7.4.8 Additional Information

None

,

14.7.4.9 Usage

Defined in profile.

14.8 OIW Defined Profiles

These profiles are defined using the conventions specified in Annex A

of ISO 9040.

14.8.1 Telnet Profile

OIW VTE-Profile Telnet-1988 (rl, r2)

14 8 1 1 Introduction

This profile provides support for TELNET- like operation for users of the ISO Virtual Terminal Service. It is based on

the IS version of ISO 9040 and ISO 9041.

14 . 8 . 1 . 2 Association Requirements

14. 8 1 . 2 .

1

Functional Units

The Urgent Data Functional Unit is optional, but should

be used whenever available.

14.8.1.2.2 Mode

This is an A-mode profile.

14.8.1.3 Profile Body

Display-objects = ^(double occurrence)*

I

{display-object-name = D, *(DISPLAY)*

do-access = "WACA,"

dimensions = "two,"

14-13
September 1990 (Stable)

x-dimension =

{ X- bound

x-addresslng

x-absolute

x-window

),

y-dimension =

{ y-bound

y- addressing

y-absolute

y-window

).

erasure-capability = repertoire-capability = repertoire-assignment = repertoire-assignment =

"unbounded,

"no constraint,"

"no, " profile- argument- rl

= "unbounded,"

= "higher only,"

= "no," = 1

"yes ,

2,

profile-argument-r2

,

<ESC> 2/5 2/15 4/2

{

'

-

. display-object-name = K, *(KEYBOARD)*

do-.access = "WACI , " dimensions = "two,"

x-dimension =

( x-bound

X- addressing

x-absolute

x-window

= "unbounded,"

= "no constraint,

).

y-dimension =

{ y -bound

y-addressing

y-absolute

y-window

= "no," = profile-argument-rl

= "unbounded,"

= "higher only,"

= "no," = 1

erasure -capability = "yes

repertoire-capability = 2,

repertoire-assignment = profile-argument-r2

,

repertoire-assignment = <ESC> 2/5 2/15 4/2

) ),

Control-objects = ^(multiple occurrence)*

{

{ *( SYNCHRONIZE)*

CO -name co-access CO-category

= SY, = "NSAC,"

= "symbolic,"

14-14
September 1990 (Stable)

CO-size = 1,

co-priority = "urgent"

}.

{ *(DISPLAY-SIGNAL)*

CO -name = DI,

CO- access = "WACA,"

co-category = "boolean,"

co-size = 5,

co-priority = "normal,"

CO- trigger = "selected"

).

{ * (KEYBOARD- SIGNAL)*

CO-name = KB,

co-access = "WACI ,

CO-category = "boolean,"

CO-size = 5,

co-priority = "normal,"

co-trigger = "selected"

},

{ * (NEGOTIATION BY INITIATOR)*

CO -name = NI

,

co-access = "WACI,"

co-category = "boolean,"

co-size = 4,

co-priority = "normal,"

co-trigger = "selected"

},

{ * (NEGOTIATION BY ACCEPTOR)*

co-name = NA,

CO- access = "WACA,"

co-category = "boolean,"

CO-size = 4,

co-priority = "normal,"

co-trigger = "selected"

},

{ *(GO-AHEAD)*

CO -name = GA,

co-access = "NSAC,"

CO-category = "boolean,"

co-size = 1,

co-priority = "normal,"

CO- trigger = "selected"

} ),

14-15
September 1990 (Stable)

Device-objects = *(double occurrence)*

{

{device-name = DI SPLAY- DEVICE

,

device-display-object = D,

device-default-co-initial-value = 1

. " true , "*( "on" )*

device -minimum-X- array- length = l,*(no constraint)*

device -minimum-Y- array- length = l,*(no constraint)*

device-control-object = SY,

device-control-object = NA,

device-control-object = DI

,

device-control-object = OA,

* ( SYNC , NEGOTIATE-ACCEPTOR , DI SPLAY- SIGNAL

,

GO-AHEAD)*

device-default-co-access = "WACA,"

device-default-co-priority = "normal"

*(other device object parameters assume corresponding

DO values)*

},

{device-name = KEYBOARD - DEVICE

,

device-display-object = K,

device-default-co-access = "WACI,"

device-default-CO-priority = "normal,"

device-default-CO- initial-value = 1

. " true , "*( "on" )*

device-minimum-X-array-length = l,*(no constraint)*

device-minimum-Y-array-length = l,*(no constraint)*

device-control-object - SY,

device-control-object = NI

,

device-control-object - KB,

device-control-object = GA, * ( SYNC , NEGOTIATE - INITIATOR , KEYBOARD - SIGNAL

,

GO-AHEAD)*

*(other device object parameters assume corresponding

DO values)*

}

) , Type of delivery control = "simple-delivery-control."

14.8.1.4 Profile Arguments

rl - is used to represent the line length as the value of

VTE parameter x-window for both display objects. This

argtoment is mandatory and takes a nonnegative integer

value. This argument is identified by the identifier

for x-window for display object D.

r2 - is used to designate the default repertoire for both

display objects. This argument is optional, if not

14-16
September 1990 (Stable)

present the full US ASCII set is the default. This

argument is identified by the identifier for repertoire

assignment for the display object D.

14 8 . 1 . 5 Profile dependent Control Object Information

This profile does not reference any Control Objects which

are not defined within this profile.

14.8. 1 .6 Profile Notes

14.8.1.6.1 Definitive Notes

1. Booleans in the KB and DI control objects are used

in this profile to correspond to TELNET commands

as follows:

Control Object Boolean TELNET

DI/KB 1 IP

DI/KB 2 AO

DI/KB 3 AYT

DI/KB 4 DM

DI/KB 5 BREAK

The equivalent of a TELNET command is achieved by

selecting the boolean that corresponds to the

desired TELNET command. Selecting a boolean in

the DI or KB control object means setting the

value of the desired boolean to "true." The usage

of the mask element of the boolean update is as specified in ISO 9041.

2. The equivalent of a TELNET SYNCH command is

achieved by updating the SY control object with

the single symbolic value of "SYNCH" (which is

mapped onto the integer value 1), and immediately

updating the DI (or KB) control object selecting

the DM boolean. IP, AO, AYT, or BREAK commands

may be accompanied by a SYNCH command by updating

the SY control object and then updating the DI or KB control object selecting both the DM and the

other desired boolean. When an update to the SY

control object is received subsequent display

object updates are discarded until an update to

the DI or KB control object is received selecting

the DM bit. If a VT-BREAK is received after an SY

14-17
September 1990 (Stable)

CO update has been received and prior to the

corresponding DI or KB CO update selecting the DM

boolean, the discarding of updates is terminated.

This is necessary because the VT-BREAK may have

caused the DI or KB CO update to be purged.

The NI and NA control objects are used to emulate

the TELNET option negotiation facility. The

facility is sjnottmetric, allowing either party to

open negotiation for a change of mode, and every

negotiation must be accepted or rejected by the

opposite party. The rules for negotiation for

each of the option controls are as stated in RFC

854 and as given below.

a. Only open negotiation for a change from the

current state.

b. Only acknowledge negotiation for a change

from the current state.

c. Do not send any object updates with a negotiation outstanding except an update to

the NI (or NA) control object to acknowledge

negotiation.

For full symmetry, both the NI and NA control

objects have the same value definition and consist

of 4 booleans with the semantics given below.

BIT Option Value

1 Remote Echo "false" Echo is local;

"true" Echo is remote

2 Suppress Go Ahead "false" Go Ahead;

"true" Suppress Go Ahead

3 Binary WACA "true" use binary WACA;

"false" use default or negotiated repertoire

for WACA display object

4 Binary WACI "true" use binary WACI

;

"false" use default or negotiated repertoire for

WACI display object

Booleans 3 and 4 control the use of the

Transparent character set for the D and K display

14-18
September 1990 (Stable)

objects respectively. A value of "true" indicates

the use of the binary repertoire; "false"

indicates the use of the negotiated repertoire.

When a party wants to change a repertoire

assignment, it must complete a successful TELNET

negotiation to change the option control. Then

the party with the access rights to the display

object in question is required to perform the

corresponding secondary attribute modal update.

The TELNET EC (erase character) command will be

mapped to a pointer relative (x:= x-1) update and

an erase current update. The TELNET EL (erase

line) command should will be mapped to an erase- full-x-array update (an erase operation where the

extent is defined as <"start-x, " (Yc ,Xc-l)> and a pointer update to set x = 1. These X dimension

updates are the only times when backward explicit

addressing is permitted.

The X address of the pointer can be moved forward

only by implicit pointer addressing. Addressing

of the Y dimension is limited to the next X- array

update operation.

The VT next X- array update operation will be sent

in place of the TELNET NVT "CR.LF" sequence.

While the "binary" repertoire is being used no mapping to pointer addressing or erase operations

will be done.

The repertoire designation "7-bit ASCII (GO+CO)"

refers to the repertoire invoked by ISO 2022

defined character set designating escape sequences

<ESC> 2/8 4/2, "void," <ESC> 2/1 4/0. The

repertoire designation "7-bit ASCII (GO only)"

refers to the repertoire invoked by the ISO 2022

defined character set designating escape sequence

<ESC> 2/8 4/2. The designation "binary" refers to

the "Virtual Terminal Service Transparent Set"

registered in the International Register under ISO

2375 register value 125 and invoked by the escape

sequence <ESC> 2/5 2/15 4/2.

No termination event list is specified so that

data buffering and delivery can be controlled

according to context. If local echoing is

enabled, the local newline or enter event shall

trigger a VT-DELIVER request. With remote echo a

14-19
September 1990 (Stable)

timeout or buffer length may be used to trigger a VT-DELIVER request. This buffer length may be 1.

14.8.1.6.2 Informative Notes

1. Users of this profile should refer to the TELNET

specification (MIL-STD-1782) and RFCs 854 and 855

for semantics of the TELNET commands. These

documents can be obtained by contacting SRI

International, DDN Network Information Center, 333

Ravenswood Ave., Menlo Park, CA 94025, (415) 859-

3695.

2. An update to the GA control object is equivalent

to the TELNET Go Ahead command.

3. If the "go ahead" facility has been negotiated

then following a VT-BREAK, only the association

acceptor has the right to send data. In the event

of VT-BREAK the echo control objects are reinitialized to "false," meaning local echo. If

remote echo is desired it must be re-negotiated

following VT-BREAK.

4. Negotiation of TELNET options other than echo,

transmit binary, and SUPPRESS GO AHEAD is not

supported by this profile. Negotiations for these

three options can take place at any time during a session.

14. 8 . 1 . 7 Specific Conformance Requirements

The following character sets are required:

o The GO character set for U.S. 7 -bit ASCII (values 32-

126),

o The full U.S. 7-bit ASCII (values 0-127). and

o The transparent character set, see Definitive Note 8 in

section 14.8.1.6.1.

14.8.2 Transparent Profile

14-20
September 1990 (Stable)

OIW VTE-Profile Transparent- 1988 (rl)

14. 8 2 1 Introduction

This profile is intended to provide a transparent mode of

operation which allows VT-users to exchange transparently

14-20-1

June 1990 Stable

uninterpreted sequences of characters but with the added

benefit of delivery control to enable the VT-users to

determine when the character sequences are to be delivered.

This profile may be used when VT-users wish to control

terminals directly through the use of embedded control

characters

.

14.8.2.2 Association Requirements

14.8.2.2.1 Functional Units

No additional functional units are required by this

profile

.

14.8.2.2.2 Mode

This is an A-mode profile.

14.8.2.3 Profile Body

Display-objects *(double occurrence)* =

{

{display -object -name = Dl

,

do-access = "WACA,"

dimensions = "one,"

X- dimensions =

( x-addressing = "not-permitted"

).

repertoire-assignment = profile -argument- rl

},

{display-object-name = D2

,

do-access = "WACI ,

dimensions = "one,"

X- dimension =

{ x-addressing = "not-permitted"

).

repertoire-assignment = profile -argument- rl

) ).

type-of-delivery-control = "simple-delivery-control."

14-21
June 1990 Stable

14.8.2.4 Profile Arguments

rl - is optional and enables negotiation of a value for

the VTE-parameter repertoire-assignment for the two

display objects (which always have the same value of

repertoire assignment when the profile is called) . The

default value of this argument is the "Virtual Terminal

Transparent Set" registered in the International

Register under ISO 2375 register value 125, invoked by

the escape sequence <ESC> 2/5 2/15 4/2. This argument

is identified by the identifier for repertoireassignment for display object Dl

.

14. 8 . 2 .

5

Profile dependent Control Object Information

This profile does not reference any Control Objects.

14.8.2.6 Profile Notes

1. This profile is intended primarily for applications

requiring a simultaneous two way exchange of sequences

of uninterpreted characters. The semantics usually

associated with the display object are not used; for

the purposes of this profile, the primary attributes of

the character-box graphic elements are actually octets

which are passed directly to the real device. There is no relationship between the elements of the X-array and

the character boxes of the real device; the secondary

attributes of the display object are not utilized. The

only operation on the display object which must be

supported is the text operation. An alternative

repertoire may be selected.

14.8.2.7 Specific Conformance Requirements

Support for the default (transparent) character set is

required. It is strongly recommended that the profile

argiament not be used.

14.8.3 Forms Profile

OIW VTE-Profile Forms-1989 (rl,r2, . . . r28)

14-22
June 1990 Stable

14.8.3.1 Introduction

This S-mode VTE-profile is intended for supporting the use

of forms based, field oriented data entry applications

between a terminal and a host system.

It provides facilities for:

defining and using screen forms,

defining field validation and field entry rules, and

controlling and validating field entry.

This VTE-profile includes support of an optional terminalend locally attached printer.

14.8.3.2 Association Requirements

14.8.3.2.1 Functional Units

The following VT functional units are required for

operation with this profile:

Enhanced access-rules,

Structured COs

,

Fields, and

Reference Information Objects

The following VT functional units are optional for

operation with this profile:

Urgent Data

14.8.3.2.2 Mode

This is an S-mode profile.

14-23
June 1990 Stable

14.8.3.3 Profile Body

Display-objects *(single occurrence)* =

{display-object-name = A,

DO-access = "WAVAR,"

dimensions = "three,"

X- dimension =

(x-bound = profile-argument-rl

,

x-addressing = "no constraint,"

x-absolute = "yes,"

x-window = x-bound

).

y- dimension =

(y-bound = profile- argument -r2

,

y-addressing = "no constraint,"

y-absolute = "yes,"

y-window = y-bound

). z- dimension =

{z -bound = "unbounded,"

z-addressing = "no constraint,"

z-absolute = "no,"

z-window = profile-argument-r3

}.

erasure-capability = "yes,"

repertoire-capability *( implicitly defined by r4)*,

repertoire-assignment = profile -argument -r4

,

font-capability *(implicitly defined by r5)*,

font -assignment = profile- argtiment-r5

,

DO-emphasis = profile -argument -r6

,

foreground-colour-capability = profile-argument-r7

,

foreground-colour-assignment = profile-argument-r8

background-colour-capability = profile-argument-r7

,

background-colour-assignment = profile-argument-r9

,

block-definition-capability = "no,"

field-definition-capability = "yes,"

max-fields = "unbounded,"

max-field-elements = profile-argument-rlO

,

access-outside-fields = profile-argument-rll

).

14-24
June 1990 Stable

Control-objects =

(

{ *(Field Definition CO)*

CO -name = FD,

CO- type -identifier = vt-b-sco-fdco

,

CO-structure = "non-parametric,"

co-access = "WAVAR" + profile-argument-rl2

,

CO-priority = "normal,"

CO-trigger = "not-selected"

),

{ *(Field Entry Instructions CO)*

CO -name = EI,

CO- type - identifier = "mandatory- feico ,

CO-structure = "non-parametric ,

CO-access = "WAVAR" + profile-argument-rl2.

CO-priority = "normal ,

CO-trigger = "not-selected"

{ *(Field Entry Pilot CO)*

CO -name = EP,

CO-type-identifier = "mandatory- fepco ,

CO-structure = "non-parametric,"

CO-access = "WAVAR" + profile-argument-rl2

,

CO-priority = "normal,"

CO-trigger = "not-selected"

),

{ *(Context CO)*

CO -name

CO- type- identifier

CO -s true ture

CO-access

CO-priority

CO-trigger

},

= CC, = vt-b-sco-cco

,

= 6, = "WAVAR,"

= "normal," = "not-selected"

{ *(Transmission Policy CO)*

CO -name

CO- type- identifier

CO-structure

CO-access

CO-priority

CO-trigger

CO-category

co-size

TP,

vt-b-sco- tpco

,

1.

"WAVAR" + profile-argument-rl2,

"normal ,

"not-selected,

"boolean,

4

14-25
June 1990 Stable

{ *(Multiple occurrence of optional COs. All

unspecified VTE- parameters of such COs are determined

by their CO- type-identifier through their registered

definition. They may include parameters specified to

be additional profile arguments, which should follow

the appropriate CO- type -identifier argument value)*

co-name = profile-argximent-rl3

,

co-type- identifier = profile-argument-rl4

).

{ *(Form Waiting Time CO)*

CO -name

CO- type- identifier

CO- structure

CO-access

co-priority

CO- trigger

CO-category

CO-size

),

WT,

"waiting- time,

1.

"WAVAR,

"normal ,

"not-selected,

" integer,

65535

*(The initial value for WT is zero, implying that a Fora

Waiting Time is not to be used.)*

*(The following four COs, (SA, UA, ST, and UT) , are registered with the OIW registration authority and are referenced by this profile.)*

{ *(As defined in 14.7.1 of this document)*

CO-name = SA,

CO-type-identifier = oiw-vt-co-misc-sa,

co-structure = 1, co-access = "WAVAR" + profile-argument-rl2

,

co-priority = "normal,"

co-trigger = "not-selected,"

co-category = "symbolic,"

co-size = 11

),

{ *(As defined in 14.

CO-name =

CO- type- identifier =

CO -structure = CO-access = CO-priority =

CO- trigger = CO-category = co-size

}.

7.2 of this document)*

UA,

oiw-vt-co-misc-ua,

1,

profile-argument-rl2,

"urgent,

"not-selected,

"symbolic ,

11

14-26
June 1990 Stable

{ *(As defined in 14.7.3 of this document)*

CO -name co-type- identifier

CO- structure

CO-access

co-priority

CO- trigger

co-category

CO-size

).

= ST, = oiw-vt-co-misc-st

,

= 1. = "WAVAR" + opposite of

profile-argument-rl2

,

= "normal ,

= "not-selected," = "integer,"

= 65535

( *(As defined in 14.7.4 of this document)*

CO-name

CO- type - identifier

CO- structure

CO-access

co-priority

co-trigger

CO-category

co-size

}

= UT, = oiw-vt-co-misc-ut

,

= 1. = opposite of profile-argument-rl2

,

= "urgent,"

= "not-selected,"

= "integer," = 65535

Device -objects *(single or double occurrence)* =

(

{device -name = D,

device-default-co-access = "WAVAR,"

device-default-CO-priority = "normal,"

device-default-co-trigger = "not-selected,"

device-default-CO- initial-value = l."true,"

device-repertoire-assignment = profile-argument-rl5

,

device-font-assignment = profile-argument-rl6

,

device -emphasis = profile-argument-rl7

,

device -foreground- CO lour- assignment = profile-argximent-rl8

,

device -background- CO lour -assignment = profile-argument-rl9

,

device-minimum-X-array- length = profile-argument-r20

,

device -minimum-Y- array- length = profile -argument- r21

,

device -control- object FD,

device -control- object CC,

device -control- obj ect SA,

device -control- object UA,

device -control- obj ect ST,

device -control- object UT,

device - control

obj ect WT,

device -control- object TP,

14-27
June 1990 Stable

device-control-object = profile-argument-r22

,

device-display-object = A

),

IF r23 = "true" THEN *(define printer)*

{device -name = P,

device -default-co-access = "NSAC,"

device-default-co-priority = "high,"

device-default-co-trigger = "not-selected,"

device-default-CO- initial-value = 1. "false,"

device-repertoire-assignment = profile- argument -r24

,

device-font-assignment = profile-argument-r25

,

device -emphasis = profile-argument-r26

,

device- foreground-colour-assignment = profile-argument-r27

,

device-background-colour-assignment = profile-argument-r28

,

device -minimum-X- array- length = profile-argument-r29

,

device -minimum-Y- array- length = profile-argument-r30

,

device-control-object = FD,

device-control-object = SA,

device-control-object = UA,

device-control-object = profile-argument-r31

,

device-display-object = A

) },

type -of- delivery- control = "simple delivery control."

FIXED Field Entry Instruction Definitions - non-parametric

Optional Field

field entry is optional. This FEI is provided for

completeness only, as a field not linked to one of the

Mandatory field. Selectable field or Protected field FEIs is

necessarily optional. This FEI can never be violated.

Mandatory Field

- field entry is mandatory. Violation of this FEI will

occur if all array elements of this field are empty when one

of the reactions FEROl (Transmit updates) or FER02

(Relinquish WAVAR) is initiated. See also the specification

of these reactions given below.

Protected Field

- the field is protected from field entry. Violation of

this FEI will occur if an attempt is made to change the

14-28
June 1990 Stable

primary or secondary attribute of any array element of this

field.

Fill Field

- all array elements k=l through k=last must have a primary

attribute. Violation of this FEI will occur if any array

element of this field is empty when one of the reactions

FEROl (Transmit updates) or FER02 (Relinquish WAVAR) is

initiated. See also the specification of these reactions

given below.

Echo Received Character

allowed field entry characters are to be echoed as received. This FEI is provided for completeness only, as by

default characters will be echoed as received unless the

field is linked to either the Echo Off or the Echo Specified

Character FEI. This FEI can never be violated.

Echo Off

- received field entry characters should not be echoed.

This FEI can never be violated.

Ignore Case

- if this FEI is linked to a field, upper and lower case alphabetic characters should be considered as equivalent

during the validation of field input against all other FEIs

linked to the same field. This affects the interpretation

of the Allowed First Characters, Allowed Characters,

Disallowed Characters and Allowed String Values FEIs,

including the precedence rules between the first three of

these FEIs. This FEI can never be violated.

Inhibit Logical Rendition Attribute Operation

- no form of logical attribute operation, with the exception

of character repertoire switching as given below, can be

performed on the field. Character repertoire changes are permitted if also permitted by Allowed First Characters or Allowed Characters, see below. This FEI is intended to be

used when the rendition secondary attributes are to be kept

under "application" control. See, for example, Allowed

First Characters for a case of reference to the field modal

values

.

DYNAMIC Field Entry Instruction Definitions - parametric

Selectable field

- the field is selectable, i.e., field entry is not

permitted but information is conveyed by the selection of

one such field from a number of alternatives.

14-29
June 1990 Stable

The manner in which the field that is the current candidate

for selection is displayed on the real device is determined

by the optional "visit" parameter of this FEI . This

parameter specifies the secondary attributes to be used for

showing or highlighting this candidate to the user. If it

is omitted, an implementation- dependent default is used.

The manner in which the field that is actually selected is

displayed on the real device is determined by the optional

"select" parameter of this FEI. This parameter specifies

the secondary attributes to be used for showing or highlighting the selected field to the user. If it is

omitted, an implementation-dependent default is used.

The mechanisms for moving among candidates and for actually

selecting the current candidate are implementation defined.

Typically, a selectable field will be considered as a candidate for selection when the cursor is placed on a character within the selectable field. Actual selection

generates the Field Selected FEE. A selected field is

indicated in a delivered update by an addressing operation

setting k=l and f and z to indicate the selected field.

These values will be reported to the host in the CCO if

WAVAR is relinquished in reaction to this FEE. Violation of

this FEI will occur if an attempt is made to change the

primary or secondary attribute of any array element of this

field.

Echo Specified Character

- specifies the character which is to be echoed to the user

in response to each allowed character entered into the

field. The secondary attributes of the echoed character may

be specified. Any secondary attribute that is not given an explicit value in the FEI takes a default value in

accordance with Definitive Note 4. This FEI can never be

violated.

Minimum Entry

- all array elements k=l through k=Minimum Entry must have a primary attribute. If Minimum Entry exceeds field size,

then all positions in the field must be filled. Violation

of this FEI will occur if any of the specified array

elements are empty when one of the reactions FEROl (Transmit

updates) or FER02 (Relinquish WAVAR) is initiated. See also

the specification of these reactions given below. When a field is associated with both the Optional Field FEI and a Minimum Entry FEI, the field is optional but if entry is

elected, the number of characters specified by the Minimum

Entry FEI must then be entered.

14-30
June 1990 Stable

Allowed First Characters

specifies a set of allowed characters for the first

character position of the field. Either primary attributes

alone or both primary and secondary attributes may be

checked; see Definitive Note 3.

Allowed Characters

- specifies a set of allowed characters for all character

positions within the field. Either primary attributes alone

or both primary and secondary attributes may be checked; see Definitive Note 3. If Allowed First Characters and Allowed

Characters are both specified for a particular field, then

the set of Allowed First Characters applies to the first

character position of the field and the set of Allowed

Characters applies to the second through last character

positions of the field.

Disallowed Characters

- specifies a set of disallowed characters for all character

positions within a field. Either primary attributes alone

or both primary and secondary attributes may be checked; see Definitive Note 3. If Allowed First Characters and

Disallowed Characters are both specified for a particular

field, then the set of Allowed First Characters applies to

the first character position of the field and the set of

Disallowed Characters applies to the second through last

character positions of the field. When a field is

associated with Allowed Characters FEI(s) and Disallowed

Characters FEI(s) that have characters in common, the common

characters are considered as disallowed.

Entry Invoke Character

specifies the attributes to be used for showing or highlighting to the user where the next character entry is

to be made. Both primary and secondary attributes, or secondary attributes alone, may be specified to over-ride

the corresponding values present in the array element

concerned. Any secondary attribute that is not given an explicit value in the FEI takes a default value in

accordance with Definitive Note 4. Fields that are not

linked to an Entry Invoke Character FEI, utilize a device

dependent entry invoke character which may or may not be

represented in the character repertoire negotiated for the

device. This FEI can never be violated.

Waiting Time

- specifies the number of seconds to wait for field entry to

complete after the cursor has been positioned within the

field. Fields that are not associated with a Waiting Time

FEI are not subject to the "Field Waiting Time Expired"

14-31
June 1990 Stable

Field Entry Event. Note that an overall waiting time for an

entire form may be set by use of the "waiting-time" control

object defined in Definitive Note 1. This FEI can never be

violated.

Allowed String Values

- specifies a list of strings which identify valid field

values. The strings are specified as either a discrete

OCTET STRING or a range of OCTET STRING, or combination of

both.

Ranges are specified using a lower "value" OCTET STRING and

a higher "value" OCTET STRING. The "value" of an OCTET

STRING is the integer value derived from the collating

sequence corresponding to the repertoire explicitly or implicitly specified for the OCTET STRING. For example, the

ISO 646 string 'AB' has the integer value 4142(16) and the

string 'ABC has the value 414243(16).

When strings of unequal length are compared, the smaller

string is filled on the right with enough spaces to make the

strings of equal length. The comparison of ISO 646 strings

'AB' and 'ABC would be accomplished by first converting the

string 'AB' to 'AB' thus creating the value 414220(16) to be

compared against the value 414243(16). The value of the

space character is derived from the collating sequence

corresponding to the repertoire identified in the field

modal attributes. If this repertoire does not contain a space, then the value 20(16) is used.

Either primary attributes alone or both primary and

secondary attributes may be checked; see Definitive Note 3.

A single set of secondary attribute values may be specified

for each individual OCTET STRING or range of OCTET STRINGS.

Allowed Numeric Values

- specifies a list of numeric strings which identify valid

field values. The strings are specified as either a discrete OCTET STRING or a range of OCTET STRING, or a combination of both.

Ranges are specified using a lower "value" OCTET STRING and

a higher "value" OCTET STRING. The "value" of an OCTET

STRING is the integer value derived from the collating

sequence corresponding to the repertoire explicitly or implicitly specified for the OCTET STRING. For example, the

ISO 646 string '12' has the integer value 3132(16) and the

string '123' has the integer value 313233(16).

14-32
June 1990 Stable

When strings of unequal length are compared, the smaller

string is filled on the left with enough zero characters to

make the strings of equal length. The comparison of ISO 646

strings '12' and '123' would be accomplished by first

converting the string '12' to '012' thus creating the value

303132(16) to be compared against the value 313233(16). The

value of the zero character is derived from the collating

sequence corresponding to the repertoire identified in the

field modal attributes. If this repertoire does not contain

a zero, then the value 30(16) is used.

Either primary attributes alone or both primary and

secondary attributes may be checked; see Definitive Note 3.

A single set of secondary attribute values may be specified

for each individual OCTET STRING or range of OCTET STRINGS.

Mutually Exclusive FEIs

Some FEIs specify field entry validation rules that are in

conflict with the rules specified by other FEIs. For

example, a particular field cannot be both "protected" and

"mandatory." Such conflicting FEIs cannot be associated

with the same field. The following table defines the sets

of conflicting FEIs.

14-33
June 1990 Stable

Table 14.1.

FEI

Optional Field

Mandatory Field

Selectable Field

Protected Field

Fill Field

Echo Received

Character

Echo Off

Ignore Case

Inhibit Logical

Rendition Attribute

Operation

Echo Specified

Character

Minimum Entry

Allowed First

Characters

Allowed

Characters

Disallowed

Characters

Entry Invoke

Character

Sets of conflicting FEIs

Conflicting FEIs

Mandatory Field, Selectable Field, Protected Field.

Optional Field, Selectable Field, Protected Field.

All except Entry Invoke Character and Waiting Time.

All.

Selectable Field, Protected Field, Allowed String Values

Allowed Numeric Values.

Selectable Field, Protected Field, Echo Off,

Echo Specified Character.

Selectable Field, Protected Field,

Echo Received Character, Echo Specified Character.

Selectable Field, Protected Field.

Selectable Field, Protected Field.

Selectable Field, Protected Field, Echo Off,

Echo Received Character i

Selectable Field, Protected Field.

Selectable Field, Protected Field,

Allowed String Values, Allowed Numeric Values.

Selectable Field, Protected Field,

Allowed String Values, Allowed Numeric Values.

Selectable Field, Protected Field,

Allowed String Values, Allowed Numeric Values,

Protected Field.

Waiting Time

Allowed String

Values

Protected Field.

Selectable Field, Protected Field,

Fill Field, Allowed First Characters, Allowed Characters

Disallowed Characters, Allowed Numeric Values.

14-34
June 1990 Stable

Allowed Numeric Selectable Field, Protected Field,

Values Fill Field, Allowed First Characters, Allowed Characters,

Disallowed Characters, Allowed String Values.

FEICO Update Syntax

In the following syntax, ASN.l Value Assignments have been

used to attach value references to values of type NULL.

This enables the values to be referenced by these names

alone, without the need to follow the identifier explicitly

with the value NULL.

FEI DEFINITIONS : := BEGIN

FEI : := CHOICE { feiO [0]

feil [1]

fei2 [2]

fei3 [3]

fei4 [4]

fei5 [5]

fei6 [6]

fei7 [7]

selectableField [8]

visit [0] IMPLICIT S

select [1] IMPLICIT S

echoSpecifiedCharacter [9]

minimumEntries [10]

allowedFirstCharacters [11]

allowedCharacters [12]

disallowedCharacters [13]

entrylnvokeCharacter [14]

[0] IMPLICIT

[ 1 ] IMPLICIT

waitingTime [15'

allowedStringValues [16^

allowedNumericValues [17]

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT NULL,

IMPLICIT SEQUENCE { ecAttributes OPTIONAL,

ecAttributes OPTIONAL )

,

IMPLICIT Character,

IMPLICIT INTEGER,

IMPLICIT CharacterValues

,

IMPLICIT CharacterValues,

IMPLICIT CharacterValues,

CHOICE { Character

,

SecAttributes )

,

IMPLICIT INTEGER,

IMPLICIT CharacterValues,

IMPLICIT CharacterValues )

optionalField FEI

mandatoryField FEI

protectedField FEI

fillField FEI

echoReceivedChar FEI

echoOff FEI

ignoreCase FEI

inhibitLogRendAttOp FEI

feiO

feil

fei2

feiS

fei4

fei5

fei6

fei7

NULL

NULL

NULL

NULL

NULL

NULL

NULL

NULL

Character : := SEQUENCE { primaryValue [0] IMPLICIT PriValue,

14-35
June 1990 Stable

attributes [1] IMPLICIT SecAttributes OPTIONAL } -- When used as one element of a comparison, secondary

-- attributes are to be compared only if the attributes

-- element is present.

CharacterValues : := SEQUENCE OF SEQUENCE { lowValue [0] IMPLICIT Character,

highValue [1] IMPLICIT PriValue OPTIONAL } -- The default for highValue is the associated

-- lowValue. Octet values specified for highValue

-- are constrained by the repertoire corresponding

-- to the lowValue value. The relationship

-- [lowValue <= highValue] must be true.

PriValue : := OCTET STRING

-- The octet string comprising a value of the PriValue

-- type is constrained to the encoding of a sequence

--of characters from the repertoires negotiated for

-- the associated Display Object. When used in the

-- ASN.l module FEI , the octet string is restricted to

-- the encoding of a single character except for its

-- use in allowedStringValues and allowedNumeric-

-- Values.

SecAttributes : := SEQUENCE { repertoire [0] IMPLICIT INTEGER OPTIONAL,

foregroundColour [1] IMPLICIT INTEGER OPTIONAL,

backgroundColour [2] IMPLICIT INTEGER OPTIONAL,

emphasis [3] IMPLICIT PrintableString

OPTIONAL,

font [4] IMPLICIT INTEGER OPTIONAL )

END *(FEI DEFINITIONS)*

FEICO "mandatory- feico" Initial Content

For each FEIRxx, xx identifies the integer value to be used

as "feirList recordlndex" in FDCOUpdate operations.

FEICOUpdate operations must use an "index" greater than 127.

Note that the character oriented FEIRs for the initial FEICO

utilize the default secondary attributes, and that the

Selectable Field FEI uses implementation- dependent defaults

for the 'visit' and 'select' secondary attributes. The FEIR

contents are specified in terms of ASN.l Value Notation

appropriate to the FEICO Update Syntax specified above.

FEIROO -- Not used --

FEIROl optionalField

14-36
June 1990 Stable

FEIR02 mandatoryField

FEIR03 selectableFleld { }

FEIR04 protectedField

FEIR05 fillFleld

FEIR06 echoReceivedChar

FEIR07 echoOff

FEIR08 IgnoreCase

FEIR09 InhibitLogRendAttOp

FEIRIO allowedCharacters {{ lowValue {'41'H},

highValue '5A'H )) -- A,B,...,Z --

FEIRll allowedCharacters {{ lowValue {'61'H),

highValue '7A'H }) -- a,b,...,z --

FEIR12 allowedCharacters {{ lowValue {'30'H},

highValue '39'H )) -- 0,1,..., 9 --

FEIR13 disallowedCharacters {{ lowValue {'41'H),

highValue '5A'H )) -- A,B,...,Z --

FEIR14 disallowedCharacters {{ lowValue {'61'H},

highValue '7A'H )) -- a,b,...,z --

FEIR15 disallowedCharacters {{ lowValue {'30'H),

highValue '39'H }} -- 0,1 9 --

FEIR16-FEIR127 -- These values are reserved --

Field Entry Event Definitions

The Field Entry Events for the mandatory FEPCO are listed

below. A parameter of type "Range" is a sequence of integer

pairs, each with an optional bitmask. Each pair gives the

end points of an interval of integer values. An integer

value lies within the range specified if, after applying the

bitmask (if given) to its binary form, it lies in any of

these intervals. The end points of an interval are included

in the values of that interval.

It is permissible for the ranges specified by the FEEs

referenced in the entry control FEPR-list of a field to

overlap. When an event occurs which is referenced in this

14-37
June 1990 Stable

way by more than one FEPR linked to the current field, the

FEPR invoked is the first FEPR in the FEPR- list which both

references the event and for which the Field Entry

Conditions are satisfied.

FEEOO

- not used.

FEEOl Logical Keystroke event (Range)

- this event takes a range of integers as a parameter, and

occurs when a Logical Keystroke occurs within the specified

range. The Logical Keystroke is either initiated by the

Logical Keystroke FER or by the human user, see Definitive

Note 8.

FEE02 Field entry complete

- this event is generated by entry of a character into the

last position in a field. It need not imply that all

character positions in the field have been entered, since

these positions are not necessarily written sequentially.

Local cursor movements, for example, may be used during

local editing to move the current entry position around the screen.

FEE03 Field selected

- this event is generated by the selection of a field that

is linked to the Selectable Field FEI . The means by which

the current candidate for selection is actually selected is

implementation dependent.

FEE04 Field Waiting Time expired

- the field waiting time specified by the Waiting Time FEI

linked to the current field has been exceeded. Fields not

linked to such an FEI are not subject to this event.

FEE05 Field Entry Instruction violation

- some of the defined FEIs imply Field Entry Validation by

the terminal VT-user. Fields linked to such FEIs are candidates for erroneous field entry. This event is

generated when such a violation occurs, thus enabling

linkage to Field Entry Reactions that may signal a visual or audible indication of such a violation, or alternatively may

terminate local entry and relinquish WAVAR. A Violation FEC

is available to allow different reactions according to which

FEIR is violated. When the reaction is to relinquish WAVAR,

the Entry-control index and FEPR index elements of the

Context Control Object will inform the host which FEPR

caused the return. If this FEPR has made use of the

Violation FEC, this FEC will identify to the host that the

violated FEIR was one of those in the list that forms the

14-38
June 1990 Stable

parameter value for the FEC, Unique identification of the

FEIR is obtained if this list contains only one FEIR. The

host can then take whatever action is appropriate to the

FEIR or FEIRs so identified.

Field Entry Condition Definitions

The elementary Field Entry Conditions for the mandatory

FEPCO are defined below. Composite conditions can be built

by use of the specified parameters, and an individual FEPR

can include multiple conditions in accordance with 20.3.5.2

of ISO 9040.

A parameter of type Action is specified either as an explicit integer value or as the current keystroke, see Definitive Note 8. Such a parameter evaluates to an integer

of the type STCO.Key defined in clause 14.7.3.7. That

clause also defines names of logical keystrokes associated

with these integers. The local actions associated with such

values are defined in Definitive Note 9.

FECOO

- not used.

FECOl No previous field

- the current field has no currently defined previous field,

in the sense of 20.3.3.4 of ISO 9040.

FEC02 No next field

- the current field has no currently defined next field, in

the sense of 20.3.3.4 of ISO 9040.

FEC03 Start of field

- the current location for the next character entry is at

the first location in the current field.

FEC04 End of field

- the current location for the next character entry is at

the last location in the current field.

FEC05 At tab stop

- the current location for the next character entry is at a tabulation stop defined by the optional Horizontal

Tabulation CO {ewos-vt-co-misc-ht ) registered with the EWOS

Registration Authority. If this CO is not present in the

VTE, this condition is deemed to be always satisfied.

FEC06 At characters (Set of character values)

14-39
June 1990 Stable

- the current location for the next character entry is at an array element whose current value is one of the specified

characters. The set of characters is specified and

interpreted in accordance with Definitive Note 3.

FEC07 Exits field (Action)

- the local action designated by the parameter value would

move the location for the next character entry out of the

current field.

FEC08 Exits forward path (Action)

- the local action designated by the parameter value would

move the location for the next character entry out of the

forward navigation path starting at the current field.

FEC09 Exits backward path (Action)

- the local action designated by the parameter value would

move the location for the next character entry out of the

backward navigation path starting at the current field.

FECIO Exits x-array (Action)

- the local action designated by the parameter value would

move the location for the next character entry out of the

current x-array.

FECll Exits y-array (Action)

- the local action designated by the parameter value would

move the location for the next character entry out of the

current y-array.

FEC12 Not FEC (FEC)

- this condition is satisfied precisely when the FEC given

as its parameter is not satisfied.

FEC13 And FECs (Set of FEC)

- this condition is satisfied when each of the conditions in

the set comprising its parameter is satisfied.

FEC14 Or FECs (Set of FEC)

- this condition is satisfied when at least one of the

conditions in the set comprising its parameter is satisfied.

FEC15 Violation (Set of FEIR Identifiers)

- this condition is provided for use in conjunction with the

Field Entry Instruction Violation FEE. Its parameter is an FEIR-list specified as a set of FEIR identifiers. Each

identifier is a pair <FEICO-name, index> where index is an integer addressing a record in the FEICO whose name is

specified. This FEC is satisfied if the FEIR whose violation

generated this event is one of the FEIRs in this FEIR-list.

14-40
June 1990 Stable

If it is used In conjunction with any other FEE then this

condition is true.

FEC16 Unconditional

- this condition is always true. It is given for

completeness only, and has the same effect as an empty set

of conditions in an FEPR.

Field Entry Reaction Definitions

The Field Entry Reactions for the mandatory FEPCO are defined below. The significance of a parameter of type

"Action" is as described for Field Entry Conditions. A

parameter of type "ResetAttribute" may take either of the

two values "reset" and "noReset." Such a parameter controls

the effect of an erase operation on the secondary attributes

of the erased elements, corresponding to the values "yes"

and • "no" for the reset-attribute parameter of a LOGICALERASE operation as defined in 19.2.3.5 of ISO 9040.

FEROO

- not used.

FEROl Transmit updates

- the host copy of the CCA is updated to correspond to the

terminal copy by the transmission of all undelivered update

operations. The operations required to update field

contents are controlled by the T-policy component of the

Field Definition Record for the fields concerned. However,

if this FER generates an FEI violation in accordance with

the specifications of the FEICO(s) present in the VTE, and

if the current field is also linked to an FEPR with event

FEE05 (FEI violation) and satisfied conditions, then this

FER is not performed and that FEPR is activated; the

original FEPR is abandoned.

FER02 Relinquish WAVAR

- the action described under Transmit Updates is performed,

followed by return of the WAVAR access right to the host.

However, if this FER generates an FEI violation in

accordance with the specifications of the FEICO(s) present

in the VTE, and if the current field is also linked to an FEPR with event FEE05 (FEI violation) and satisfied

conditions, then this FER is not performed and that FEPR is

activated; the original FEPR is abandoned.

FER03 Erase field right (Reset attribute)

- the primary attribute value is cancelled for all elements

of the current field from the current character entry

14-41
June 1990 Stable

location to the end of the field. The effect on the

secondary attribute values is determined by the resetattribute parameter as described above.

FER04 Erase path right (Reset attribute)

- the primary attribute value is cancelled for all elements

of all unprotected fields in the forward navigation path

containing the current field, from the current character

entry location onwards. Note that the forward navigation

path may not terminate, as its definition in 20.3.3.4 of ISO

9040 does not prohibit looping. When a loop is entered

during this operation, the operation terminates when all

elements of the entered loop have been erased. The effect

of this operation on the secondary attribute values is

determined by the reset-attribute parameter as described

above

.

FER05 Local action (Action)

- that local action is performed which is designated by the

given parameter value. The specification of these local

actions is given in Definitive Note 9.

FER06 Logical Keystroke (Action)

- initiate the FEPR processing which would occur if the

given keystroke had occurred. This may itself cause the

Logical Keystroke FER and hence recursive processings of

FERs. Processing of current FERs is suspended until this

recursive processing is complete. During recursive

processing, the current keystroke is taken as the argument

to this FER. When the recursive processing is complete, the

previous keystroke is restored and processing of current

FERs is resumed.

FER07 Update ST CO (Action)

- the integer value corresponding to the given parameter is

written to the Sequenced Terminal CO. This FER will usually

be followed by a Transmit Updates or Relinquish WAVAR FER to

communicate the update to the application.

FER08 Update UT CO (Action)

- the integer value corresponding to the given parameter is

written to the Unsequenced Terminal CO. This update will be

communicated to the application immediately.

FER09 Execute RIO record (RIO record id)

- an EXECUTE -RECORD operation is performed on the RIO record

specified in the parameter, in accordance with 22.4.1 of ISO

9040.

FEROlO Call RIO record (RIO record id)

14-42
June 1990 Stable

- a CALL-RECORD operation is performed on the RIO record

specified in the parameter, in accordance with 22.4.2 of ISO

9040.

FERll Visual indication

- present a visual indication in response to Field Entry

Instruction violations.

FER12 Audible indication

- present an audible indication in response to Field Entry

Instruction violations.

FER13 Conditional branch (if: FEC, then: Optional sequence

of FER, else : Optional sequence of FER)

- if the condition given by the "if" parameter is satisfied

then perform the sequence of reactions given by the "then"

parameter, else perform the sequence of reactions given by

the "else" parameter.

FER14 Prevent further entry

- it is recommended that if a type-ahead buffer is in use by

the local user interface, this reaction should prevent

further entry into the buffer. Attempted entry may then

sound an alarm or be signalled by some other local means,

but is not an FEI violation. If the WAVAR access right is

relinquished without this reaction being invoked, the buffer

may continue to accept entries. Entry into the buffer is

resumed when WAVAR is next returned to the terminal. It is

not a violation of this profile specification if the

terminal VT-user does not behave in the intended manner.

FER15 Write disallowed character

- the most recent disallowed character is written as if it

were not disallowed. If there has been no disallowed

character, the effect is null. This FER is used when it is

desired to trap the entry of a particular character, not to

forbid it but instead to generate some other reactions in

addition to the character entry.

FER16 Write string (Character string)

- the character string given as a parameter is written as LOGICAL TEXT to the current entry location without regard to

FEICO control. If the end of the field is reached before

the string has been written in its entirety, the reaction is

terminated prematurely.

Field Entry Pilot Update Syntax

14-43
June 1990 Stable

In the following syntax, ASN.l Value Assignments have been

used to attach value references to values of type NULL.

This enables the values to be referenced by these names

alone, without the need to follow the identifier explicitly

with the value NULL.

FEPR DEFINITIONS : := BEGIN

FEE : := CHOICE { logicalKeystroke

fee02

fee03

fee04

fee05

[1] IMPLICIT Range,

[2] IMPLICIT NULL,

[3] IMPLICIT NULL,

[4] IMPLICIT NULL,

[5] IMPLICIT NULL )

f ieldEntryComplete FEE := fee02 NULL

f ieldSelected FEE := fee03 NULL

fieldWaitTimeExpired FEE := fee04 NULL

feiViolation FEE := fee05 NULL

FEC : := CHOICE { fecOl

fec02

fec03

fec04

fec05

atChar

exitsField

exitsForwardPath

exitsBackwardPath

exitsXarray

exitsYarray

not

and

orviolation

fee 16

I ] IMPLICIT

2] IMPLICIT

3] IMPLICIT

4] IMPLICIT

5] IMPLICIT

6] IMPLICIT

7] Action,

8] Action,

9] Action,

10] Action,

II] Action,

12] FEC,

13] IMPLICIT

14] IMPLICIT

15] IMPLICIT

feicoName

recordlndex

[16] IMPLICIT

NULL,

NULL,

NULL,

NULL,

NULL,

FEI . CharacterValues

,

SET OF FEC,

SET OF FEC,

SET OF SEQUENCE

PrintableString,

INTEGER }

,

NULL ) noPreviousField

noNextField

startField

endField

atTab

unconditional

FEC : := fecOl NULL

FEC : := fec02 NULL

FEC : := fec03 NULL

FEC : := fec04 NULL

FEC : := fec05 NULL

FEC : := feci 6 NULL

14-44
June 1990 Stable

FER : := CHOICE { ferOl [1] IMPLICIT NULL,

fer02 [2] IMPLICIT NULL,

eraseFieldRight [3] IMPLICIT ResetAttribute

,

erasePathRight [4] IMPLICIT ResetAttribute

local [5] Action,

logicalKeystroke [6] Action,

updateSTCO [7] Action,

updateUTCO [8] Action,

executeRIO [9] IMPLICIT RIORecordID,

callRIO [10] IMPLICIT RIORecordID,

ferll [11] IMPLICIT NULL,

ferl2 [12] IMPLICIT NULL,

branch [13] IMPLICIT SEQUENCE { if [1] FEC,

then [2] IMPLICIT SEQUENCE OF FER OPTIONAL,

else [3] IMPLICIT SEQUENCE OF FER OPTIONAL ),

ferl4 [14] IMPLICIT NULL,

ferl5 [15] IMPLICIT NULL,

writeString [16] IMPLICIT SEQUENCE OF

FEI .Character

-- The string written by this FER is the

-- concatenation of the strings specified by

-- the individual FEI . Character values. -- )

transmitUpdates

relinquishWAVAR

visuallndication

audiblelndication

preventFurtherEntry

writeDisallowedChar

FER

FER

FER

FER

FER

FER

ferOl NULL

fer02 NULL

ferll NULL

ferl2 NULL

ferl4 NULL

ferl5 NULL

RIORecordID : := SEQUENCE { rioName [1] IMPLICIT PrintableString OPTIONAL,

-- optional if there is only 1 RIO in the VTE

recordID [2] IMPLICIT PrintableString }

Range : := SEQUENCE OF SEQUENCE { [1] IMPLICIT STCO.Key,

[2] IMPLICIT STCO.Key OPTIONAL,

mask [3] IMPLICIT BIT STRING OPTIONAL }

-- The first two values of each trio represent an

-- interval of logical keystroke values. The second

-- value in each pair shall not be smaller than the

-- first value. If the second value is omitted, the

-- interval contains only the specified first value.

-- If the optional mask is given, then the value being

14-45
June 1990 Stable

-- tested is bitwise logically ANDed with the mask

-- before being compared with the end points of the

-- interval.

ResetAttribute : := BOOLEAN

reset

noReset

ResetAttribute

ResetAttribute

:= TRUE

:= FALSE

Action : := CHOICE {

current

[1] IMPLICIT STCO.Key,

[2] IMPLICIT NULL }

currentKeystroke Action : := current NULL

-- The ASN.l module STCO is defined in the specification of

-- the Sequenced Terminal CO in clause 14.7.3. STCO.Key is

--an integer type with a named number list, each named

-- number representing a specific logical keystroke as

-- defined for that CO.

END *(FEPR DEFINITIONS)*

FEPCO "mandatory- fepco" Initial Content

For each FEPRxx, xx identifies the integer value to be used

as "feprList recordlndex" in FDCOUpdate operations.

FEPCOUpdate operations must use an "index" greater than 127.

The FEPR contents are specified in terms of ASN.l Value

Notation appropriate to the FEPCO Update Syntax specified

above. Note that "shiftTab" is a named integer of type

STCO.Key. The local action it designates is defined in

Definitive Note 9 to be movement of the current character

entry position to the first location of the next field in

the forward navigation path.

FEPR No Component ASN.l Description

FEPROO Not used -

FEPROl FEE logicalKeystroke { { 0, 65535 } } FEC unconditional

FEROl updateSTCO currentKeystroke

FER02 relinquishWAVAR

FEPR02 FEE f ieldEntryComplete

FEC noNextField

FER relinquishWAVAR

14-46
June 1990 Stable

FEPR03 FEE f ieldEntryComplete

FEC not noNextField

FER local shiftTab

FEPR04 FEE fieldSelected

FEC unconditional

FER re linqui shWAVAR

FEPR05 FEE fleldWaitTlmeExpired

FEC noNextField

FER re 1 inqui shWAVAR

FEPR06 FEE fieldWaitTimeExpired

FEC not noNextField

FER local shiftTab

FEPR07 FEE feiViolation

FEC unconditional

FER visuallndication

FEPR08 FEE feiViolation

FEC unconditional

FER audiblelndication

FEPR09-

FEPR127 -- Reserved --

14.8.3.4 Profile Arguments

rl - is optional and provides for the negotiation of a value for the VTE-parameter x-bound. It takes an

integer value greater than zero. Default is 80.

r2 - is optional and provides for the negotiation of a value for the VTE-parameter y-bound. It takes an integer value greater than zero. Default is 24.

r3 - is optional and provides for the negotiation of a value for the VTE-parameter z -window. It takes an integer value greater than zero. Default is 1.

r4 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter repertoire-assignment.

The value for the VTE-parameter repertoire-capability

is implied by the number of occurrences of this profile

argument. Default is a single occurrence with the

value {value iso2022 {'2842'H)) of ASN.l type

14-47
June 1990 Stable

CDS .RepertoireAssignment as defined in ISO 9041,

designating the GL set ISO 2375 Reg. No. 6 (ASCII).

r5 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter font-assignment. The

font -assignment -type component of a font -assignment

value is an ASN.l OBJECT IDENTIFIER that designates a registered sjmtax and semantics for the fontassignment-value component. The value for the VTEparameter font- capability is implied by the number of occurrences of this profile argument. If there are no explicit occurrences of this profile argument then the

font- capability and font -assignment VTE-parameters take

the default values specified in ISO 9040.

r6 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value(s) for the VTE-parameter DO-emphasis. The syntax

and semantics for this VTE-parameter are specified in

Definitive Note 6, and for this profile argument are specified in B.17.4 of ISO 9040. The default value for

the occurrence corresponding to each unspecified

subattribute is the ASN.l PrintableString of length 1 specifying the explicit modal default value for that

subattribute

,

r? ~ is optional and provides for the negotiation of a value for the VTE-parameters

f o r e g r o u n d - c o 1 o u r - c a p ab i 1 i t y and

background-colour-capability. Default is 8. This

argument is identified by the identifier for the

VTE-parameter foreground-colour-capability for display

object A.

r8 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

foreground-colour-assignment. The default values for

unspecified occurrences of this profile argument are

the corresponding values from the ordered list

{"white," "black," "red," "cyan," "blue," "yellow,"

"green," "magenta"). There are no default values if

the value of the VTE-parameter foreground-colourcapability exceeds 8.

r9 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

background-colour-assignment. The default values for

14-48
June 1990 Stable

unspecified occurrences of this profile argument are

the corresponding values from the ordered list

{"black," "white," "cyan," "red," "yellow," "blue,"

"magenta," "green"). There are no default values if

the value of the VTE-parameter background-colourcapability exceeds 8.

rlO - is optional and provides for the negotiation of a value for the VTE-parameter max-field-elements

.

Default is 1

.

rll - is optional and provides for the negotiation of a value for the VTE-parameter access-outside-fields

.

Default is "not allowed."

rl2 - is mandatory and provides for the negotiation of a value for the VTE-parameter CO-access for the Field

Definition, Field Entry Instruction, Field Entry Pilot,

Transmission Policy, Sequenced Application, Unsequenced

Application, Sequenced Terminal, and Unsequenced

Terminal control objects. If the VT-association

initiator is the terminal VT-user, it takes the value

"WACA," otherwise it takes the value "WACI . " This

argument is identified by the identifier for CO-access

for control object UA.

rl3 - is optional, may occur a number of times and provides

for the negotiation of a value for the VTE-parameter

CO-name for optional registered COs . By default no optional COs are invoked.

rl4 - is optional, may occur a number of times and provides

for the negotiation of a value for the VTE-parameter

CO-type-identifier for optional registered COs. The

particular generic type concerned is determined from

the CO- type-identifier by the register entry. The

value vt-b-sco-nullrio selects an empty RIO. An

occurrence of the previous argument specifies the

presence of an optional CO in the VTE-profile. An

occurrence of this argument is required for every

occurrence of the previous argument. By default no optional COs are invoked.

rl5 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value(s) for the VTE-parameter device-repertoireassignment for the main device. Default is "null" for

each unspecified occurrence.

14-49
June 1990 Stable

rl6 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter device -font- assignment

for the main device. Default is "null" for each

unspecified occurrence.

rl7 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value(s) for the VTE-parameter device -emphasis for the

main device . The syntax and semantics for this VTEparameter are specified in Definitive Note 6, and for

this profile argument are specified in B.17.4 of ISO

9040. Default is "null" for each unspecified

occurrence

.

rl8 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

device-foreground-colour-assignment for the main

device. Default is "null" for each unspecified

occurrence

.

- is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

device-background-colour-assignment for the main

device. Default is "null" for each unspecified

occurrence

.

- is optional and provides for the negotiation of a value for the VTE-parameter

device -minimum-X- array- length for the main device. It

takes an integer value greater than zero. Default is

the value of x-bound for the display object.

r21 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-Y-array- length for the main device. It

takes an integer value greater than zero. Default is

the value of y-bound for the display object.

r22 - is optional, may occur a number of times and provides

for the negotiation of additional values for the VTEparameter device-control-object for the main device.

By default there are no additional values.

r23 - is a special profile argument identified by the

special-profile-arg-ident "Pp-1." It is optional and

provides for the negotiation of a printer device.

Default is "false."

14-50
June 1990 Stable

r24 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter device-repertoireassignment for the printer device. Default is "null"

for each unspecified occurrence.

r25 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter device -font -assignment

for the printer device. Default is "null" for each

unspecified occurrence.

r26 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value(s) for the VTE-parameter device -emphasis for the

printer device. The syntax and semantics for this VTEparameter are specified in Definitive Note 6, and for

this profile argument are specified in B.17.4 of ISO

9040. Default is "null" for each unspecified

occurrence

.

r27 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

device-foreground-colour-assignment for the printer

device. Default is "black" for each unspecified

occurrence

.

r28 - is optional, may occur a number of times in an ordered list and provides for the negotiation of a value (s) for the VTE-parameter

device-background-colour-assignment for the printer

device. Default is "white" for each unspecified

occurrence

.

r29 - is optional and provides for the negotiation of a value for the VTE-parameter

device-minimum-X-array- length for the printer device.

It takes an integer value greater than zero. Default

is the value of x-bound for the display object.

r30 - is optional and provides for the negotiation of a value for the VTE-parameter

device -minimum-Y-array- length for the printer device.

It takes an integer value greater than zero. Default

is the value of y-bound for the display object.

r31 - is optional, may occur a number of times and provides

for the negotiation of additional values for the VTEparameter device-control-object for the printer device.

By default there are no additional values.

14-51
June 1990 Stable

14. 8 . 3 . 5 Profile Dependent Control Objects

This profile uses the OIW registered Control Objects SA, UA,

ST and UT. The profile defined values are specified in the

body of this profile. The CO specifications require the

usage of each CO to be specified in the profile. This is as follows

.

14.8.3.5.1 Sequenced Application CO

This Control Object is defined in clause 14.7.1. It

has co-category "symbolic." Update of this CO with the

value "audible_alarm" sounds an audible alarm in the

terminal. Update with the value "visual_alarm"

generates a visual indication of a signal from the

application. All other values have no effect.

14 . 8 . 3 . 5 .

2

Unsequenced Application CO

This Control Object is defined in clause 14.7,2. It

has CO-category "symbolic." Update of this CO with the

value "audible_alarm" sounds an audible alarm in the

terminal. Update with the value "visual_alarm"

generates a visual indication of a signal from the

application. All other values have no effect.

14.8.3.5.3 Sequenced Terminal CO

This Control Object is defined in clause 14.7.3. It

has CO-category "integer." It is updated by the Update

ST CO FER, and may be used to communicate uninterpreted

keystrokes to the application.

14.8.3.5.4 Unsequenced Terminal CO

This Control Object is defined in clause 14.7.4, It

has co-category "integer." It is updated by the Update

UT CO FER and is used to communicate uninterpreted

keystrokes to the application urgently.

.8.3.6 Profile Notes

14 8 . 3 . 6 .

1

Definitive Notes

1. The WI control object provides a mechanism for the

application VT-uscr to specify a time in which all

14-52
September 1990 (Stable)

the fields of a form must be completed. The

terminal VT-user starts the timer at the time when

it receives WAVAR. If the timer expires, further

entry by the device is stopped, all undelivered

updates are transmitted, and WAVAR is

relinquished. Hie undelivered updates are transmitted followed by an update to this control

object. The WT update is made using the current

value of the WT control object. The devicecontrol-object VTE-parameter is used to link this

CO to the input device that it controls . The data

element of this CO specifies the waiting time in

seconds. A zero value signifies that a Form

Waiting Time is not to be used. The initial value

of this data element is zero.

2. If there are two or more Character-oriented FEIs

of the same type associated with the same field,

they are equivalent to a single FEI of that type

whose parameter is the concatenation of the

individual parameter values

.

3. The following parameteric FEIs and FECs defined in

clause 14.8.3.3 test equality of characters:

Allowed First Characters FEI

Allowed Characters FEI

Disallowed Characters FEI

Allowed String Values FEI

Allowed Numeric Values FEI

At Characters FEC

The characters for each such FEI or FEC are specified by a parameter that includes an optional

set of secondary attributes. If this set is

included, the test is on both primary and

secondary attributes; otherwise it is on primary

attributes only. If the test is on primary

attributes only, then characters which pass the

test are allowed, disallowed or accepted, as appropriate, irrespective of the values of their

secondary attributes. The set of secondary

attributes need not specify an explicit value for

every secondary attribute; i-n particular the empty

set is permissible. Default values are used for

unspecified secondary attributes. These are determined in accordance with Definitive Note 4.

4. The parameter values for a number of FEIs, FECs

and FERs require default values to be used for

14-53
September 1990 (Stable)

secondary attributes when such values are not

specified explicitly by the parameter. The first

choice default for each secondary attribute value

is the field modal attribute value at the time

that the FEI , FEC or FER is accessed. A first

choice default value of "null" is resolved as specified in 19.2.3.1 of ISO 9040 for the LOGICALTEXT update operation.

When the Character oriented FEIs associated with a particular field have characters in common, the

precedence algorithm given below is used.

The Allowed First Characters FEI takes precedence

over the Allowed Characters and Disallowed

Characters FEIs for field character position k=l.

The Disallowed Characters FEI takes precedence

over the Allowed Gh.aracters FEI for all field

character positions.

The following example illustrates the conflict

resolution algorithm. When a particular field is

linked to the following three Character oriented

FEIs:

Allowed First Characters = a Allowed Characters = a,b

Disallowed Characters = a

the field must be entered with the letter "a" in

the first character position of the field. The

remaining character positions in the field are limited to containing the letter "b . " Therefore

field entry would be limited to a form such as "abbbb. ..."

The following syntax and semantics is mandatory

for the emphasis and device-emphasis VTEparameters. The scheme of B.17.3 of ISO 9040 is

to be adopted except that the maximum length for an ASN.l PrintableString used as an emphasis value

is increased from 6 characters to 8 characters.

Values "B" (Boxed) and "C" (Encircled) are deleted

from subattribute "b." Two further subattributes

are added, denoted by "g" and "h." The table of

allowed character values, ISO 6429 SET GRAPHIC

RENDITION parameter values and associated

semantics given in B.17.3 of ISO 9040 is augmented

by the addition of:

14-54
September 1990 (Stable)

Subattribute "g" values

= "I" 3 Italicized characters

14-5A-1

June 1990 Stable

= "U" * 23 Upright, not Italicized

characters

= " " - No change

As in B.17.3 of ISO 9040, * indicates the value

which is the explicit modal default value for the

subattribute . Not all the values of this scheme

need to have a 1-1 correspondence with emphasis

levels available on the real device. The device

object defines the real mapping.

7. When default values are defined for a multipleoccurrence profile argument and fewer occurrences

are negotiated than are required by the value of a parent VTE-parameter , the remaining occurrences

still take the specified default values.

8. Every action corresponding to the operation of an object updating device shall be assigned a non- negative integer value. This value shall be

interpreted as a logical keystroke in accordance

with the definitions of the Sequenced Terminal CO

and Unsequenced Terminal CO in clauses 14.7.3 and

14,7.4.

Values in the range 0-255 are used to generate

entry of characters into the Display Object from

the available repertoires. Values greater than

255 generate the Logical Keystroke FEE and thus

have effects that are under the control of the

FEPCOs present in the VTE.

9. A minimum set of local actions is defined within

this profile, but implementors may extend this as required. A host implementation thus may not know

what local action is being over-ridden when it

requests that a particular logical keystroke

should be notified to the host. To prevent this

from limiting the capabilities of the terminal,

two keystroke combinations that differ only in the

inclusion or otherwise of the ALT key are required

to have the same potential local action. Host

implementations are advised not to over-ride the

action of both such keystrokes.

The defined minimum set of local actions concerns

control of the current entry location. At any

time when the terminal possesses the WAVAR access

right, there is a well-defined Display Object

array element which is the current candidate for

14-55
June 1990 Stable

update by a character entry operation, as described in Informative Note 4. If this element

lies outside of any field, or within a protected

field, update is prohibited unless the negotiated

value of the VTE-parameter access-outside-fields

is "yes," but the array element is still defined.

Neither this location nor that of any cursors which the implementation may use to indicate such

elements is recorded in the CCA. It is separate

from the current position of either the display

pointer or the logical pointer, and movement of

this entry location is a purely local action.

Table 14.2. Local actions that move entry location

Name Unshifted action Shifted action

leftArrow X = X- 1 k = k-1

rightArrow X = x+1 k = k+1

upArrow y = y-1 f = f-1, k = 1 downArrow y = y+1 f = f+1, k = 1 home (x,y,z) = "start-y" (k,f,z) = "start-k"

end (x.y.z) = "end-y" (k,f,z) = "end-k"

pageUp z=z-l, x=l, y= 1 z = z-1, f = 1, k = 1 PageDown z = z+1 , x = 1 , y = 1 z = z+1 , f = 1 , k = 1 tab f = next(f) , k = 1 backTab f = previous (f), k = 1

The names given in the first column of table 14.2

are the identifiers of named integers of type

STCO.Key. The ASN.l module STCO is defined as part of the specification of the Sequenced

Terminal Control Object in clause 14.7.3. These

identifiers or the corresponding integers are used

to designate the local actions specified in the

second column. If the initial lower case letter

of such a name is converted to upper case and

prefixed with "shift" then it designates the local

action specified in the third column.

In this table, "=" is used as an assignment

operator. The unshifted actions reference array

elements by normal (x, y, z) coordinates while the

shifted actions reference them by logical (k, f,

z) coordinates. The values next(f) and

previous (f) are defined in 19.1.3.2.2 of ISO 9040,

"start-k" and "end-k" are defined in 19.1.3.5 of

14-56
September 1990 (Stable)

ISO 9040, and "start-y" and "end-y" are defined in

19.1.1.4 of ISO 9040.

If the initial or final coordinate values are undefined then the local action is implementationdependent. However, a host implementation can use

the mandatory FEPCO to control the behavior in

such circumstances. Field Entry Conditions are provided to test whether a particular local action

would make the entry location leave the current

field or navigation path, as defined in clause

14.8.3.3.

10. If the VTE-parameter access-outside-fields takes

the value "allowed", when data entry terminates,

the display pointer shall be aligned with the

current entry location by an explicit or implicit

addressing operation. In this way, the value of

the display pointer notifies the application of

the current entry location.

11. Use of the values "F" (Framed) and "C" (Encircled)

for emphasis subattribute "h" causes groups of

characters within a single field which have this

subattribute value to be outlined by a frame. The

two subattributes differ only in that the external

corners of the frame are squared if value "F" is

used and rounded if value "C" is used. An

external corner is where two lines meet in a L

shape, as distinct from a T junction and from the

intersection of two lines. The nature of the

external corner is controlled by the subattribute

value of the array element on the inside of the corner.

More precisely, a character box element is defined

to be within frame (f,z) if it is in the field

with coordinates (f,z) and has either the framed

or encircled attribute. A character box element

is defined to be without frame if either it is not

in any field or it does not have either the framed

or encircled attribute. In the image of a y-array

on the real device, a line is drawn between two

adjacent images of character box elements if they

are within different frames, or if one is within a frame and one is without frame. In addition if a character box element is within some frame, a line

is drawn along any edge of that element which is

not in common with any other character box

14-57
September 1990 (Stable)

element, i.e., along any edges which are part of

the image of the boundary of the Display Object.

14.8.3.6.2 Informative Notes

1. Updates by the application VT-user (only possible

within the z -window) are not necessarily

immediately imaged to the (human user of the)

terminal VT-user unless the real window of the

device is currently positioned over such an

update. Such updates may move the real window if

a VT-DELIVER indication is received.

When WAVAR is relinquished by the application

VT-user the window may be moved so that the field

addressed by the CCO is within the window.

Application VT-user addressing operations that

advance z to a higher address which is outside of

the z -window cause the z -window to move and

include one or more new y- arrays for which no fields are defined. As the z-window moves, one or more y-arrays at lower addresses will no longer be

included in the z-window. The field definition

records for such y-arrays are implicitly deleted.

2. Several of the descriptions of Field Entry

Instructions refer to 'empty' array elements of

the Display Object. This is to be interpreted in

the sense of 13.2 of ISO 9040. Note that in this sense an array element containing a space

character is not empty. The representation of an empty array element on the real device is

implementation-dependent, but for this reason it

is recommended that the representation used should

be distinct from that of a space character.

3. The descriptions of a number of Field Entry

Conditions refer to the current field and to the

current location for the next character entry.

Typically this current location will be indicated

to the human user by a visible cursor. When this

location lies within a defined field, that field

is the current field and the Entry Invoke

Character FEI may be used to specify the nature of

the visible cursor. However, a terminal

implementation may allow the visible cursor to be

moved outside of any defined field. While this is

so, the representation of the cursor is

14-58
September 1990 (Stable)

implementation dependent, the current field is

undefined and no FEPRs are active.

14 . 8 . 3 . 7 Specific Conformance Requirements

For further agreement.

14.8.4 X3 Profile

OIW VTE-Profile X3-1989 ( rl , r2, r3, r4, r5, r6 )

14.8.4.1 Introduction

This profile provides support for CCITT X.3 PAD compatible

operation.

The purpose of this profile is two-fold:

o to provide a transitional environment for applications

that assume the availability of X.3 parameters with

which to control the behavior of the terminal -system.

o to facilitate a gateway function between ISO-VTP and

X.3.

14. 8 .4.

2

Association Requirements

14.8.4. 2.1 Functional Units

The Structured CO Functional Unit is mandatory.

The Urgent Data Functional Unit is optional.

14.8.4.2.2 Mode

This is an A-mode profile.

14.8.4.3 Profile Body

Display-objects =

{

{display-object-name = Dl

,

DO-access = profile-argument-rl

,

dimensions = "one,"

14-59
September 1990 (Stable)

X- dimension =

{ x-bound = "unbounded,"

x-addressing = "not-permitted,"

x-absolute = "no,"

x-window = 0

14-60
September 1990 (Stable)

repertoire-assignment = <ESC> 2/5 2/15 4/2

*( VTS Transparent Set )*

).

{display-object-name = D2

,

DO-access = opposite of profile-argument-rl

,

dimensions = "one,"

X- dimension =

{ X- bound

X- addressing

x-absolute

X- window

repertoire -assignment

),

= "unbounded,"

= "not-permitted,"

= "no," = 0

= <ESC> 2/5 2/15 4/2

*( VTS Transparent Set )*

).

Control-obj ects =

{

{ *( PAD - Each element of the PAD CO represents a CCITT PAD

parameter. The CO-element-id of each element has been

chosen so that it would be same value as the CCITT PAD

parameter number that it represents . The PAD CO is

used both to set CCITT PAD parameter-equivalent values

and to reply to an update to the READ CO. See

Definitive Note 25 for conventions concerning updates

to this CO. )*

CO -name

CO -structure

co-access

co-priority

CO- trigger

{ *( X.3 parameter

CO-element-id = CO-category = co-size =

{ *( X.3 parameter

CO-element-id = CO-category = co-size =

{ *( X.3 parameter

CO-element-id = CO-category = CO-size =

)*

= PAD, = 22, = "NSAC," = "normal," = "not-selected,"

1 -- PAD recall

1.

"transparent,

8 }, 2 -- PAD echo )*

2,

"boolean,"

1 ).

3 -- Data Forwarding Character )*

"boolean,

7 ),

14-60-1

June 1990 Stable

*( X.3 parameter 4 -- Idle Timer Delay )*

CO -element -id = 4,

CO- category = "integer,"

co-size =255 )

,

*( X.3 parameter 5 -- Ancillary Device Control )*

co-element- id = 5,

CO-category = "boolean,"

co-size = 1 )

,

*( X.3 parameter 6 -- Control of PAD Signals )*

co-element- id = 6,

CO-category = "transparent,"

co-size = 4 )

,

*( X.3 parameter 7 -- PAD on receipt of Break )*

co-element- id = 7,

CO-category = "boolean,"

co-size = 5 )

,

*( X.3 parameter 8 -- Discard Output )*

co-element-id = 8,

CO-category = "boolean,"

co-size = 1 )

,

*( X.3 parameter 9 -- Padding After <CR> )*

CO-element-id = 9,

CO-category = "integer,"

co-size = 7 )

,

*( X.3 parameter 10 -- Line Folding )*

co-element-id = 10,

co-category = "integer,"

co-size =255 )

,

*( X.3 parameter 11 -- Device Speed )*

co-element-id = 11,

CO-category = "symbolic,"

co-category = 19 )

,

*(X.3 parameter 12 -- Flow Control by Device )*

co-element-id = 12,

CO-category = "boolean,"

co-size = 1 )

,

*( X.3 parameter 13 -- Insert <LF> after <CR> )*

co-element-id = 13,

CO-category = "boolean,"

co-size = 3 )

,

*( X.3 parameter 14 -- Linefeed Padding )*

CO-element-id = 14,

CO-category = "integer,"

co-size = 7 )

,

*( X.3 parameter 15 -- Editing )*

co-element-id = 15,

co-category = "boolean,"

co-size = 1 }

,

14-61
June 1990 Stable

*( X.3 parameter 16 -- Character Delete )*

co-element- id =16,

co-category = "character,"

co-repertoire-assignment *( any from CO )* ^ = "void," "void," <ESC> 2/1 4/0,

co-size = 1 )

,

*( X.3 parameter 17 -- Line Delete )*

co-element-id = 17,

co-category = "character,"

co-repertoire-assignment *( any from CO )* = "void," "void," <ESC> 2/1 4/0,

co-size = 1 } , , xa. *( X.3 parameter 18 -- Line Display )*

co-element-id = 18,

co-category = "character,"

co-repertoire-assignment *( any from CO )* = "void," "void," <ESC> 2/1 4/0,

co-size = 1 ) , . 1 \*

*( X.3 parameter 19 -- Editing Service Signals )*

co-element- id = 19,

co-category = "transparent,"

co-size = 8 )

,

*( X.3 parameter 20 -- Echo Mask )*

co-element-id = 20,

co-category = "boolean,"

co-size = 8 }

,

*( X.3 parameter 21 -- Parity Treatment )*

co-element-id = 21,

co-category = "boolean,"

co-size = 2 )

,

*( X.3 parameter 22 -- Page Wait )*

co-element- id = 22,

co-category = "integer,"

co-size = 256 )

{ ^ ( READ " Each boolean of the READ CO represents an element- id of

the PAD CO with the same identifying value. The READ

CO is used to request the current values of PAD CO,

which may have been changed by some local agent. See

the description of the PAD CO for how the update to

this CO modifies the access to the PAD CO. )* co-name = READ,

CO- structure =1,

co-access = opposite of profile-argument-rl

,

co-priority = "normal,"

co-trigger = "not-selected,"

co-category = "boolean,"

co-size = 22

14-62
June 1990 Stable

).

{ *( Break Out-of-Band - receipt of this control object represents "X.25

Interrupt"; use is applicable when boolean 1 of

element-id 7 in PAD CO has the value "true." )*

CO -name = BO,

co-structure = 1,

CO-access = profile-argument-rl

,

co-priority = "urgent,"

co-trigger = "not-selected,"

CO-category = "symbolic,"

co-size = 1

{ *( Break In- Band - receipt of this control object represents "indication

of break"; use is applicable when boolean 3 of elementid 7 in PAD CO has the value "true." )*

),

CO -name CO -structure

CO-access

co-priority

co-trigger

CO-category

co-size

).

= BI, = 1. = profile-argument-rl

,

= "normal ,

= "selected,"

= "symbolic,"

= 1

14-63
June 1990 Stable

{ *( CUD - This CO is used to optionally convey Call User Data

which is normally carried in the CCITT PAD call. The

CO is not updatable, but may be given initial content

value during association establishment by special

profile arguments r2 and r3. The CO is parametric,

with two elements, one representing the protocol

identifier field, and the other representing the call

data field containing user data. )*

CO -name = CUD,

CO-structure = 2,

CO-access = "no-access,"

( *( Protocol Identifier )*

co-category = "character,"

co-repertoire-assignment *( VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 4 }

,

{ *( User Data )*

co-category = "character,"

co-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 124 } },

{ *( DTE - This CO is used to optionally indicate the calling and

called DTE addresses which are normally available in a true CCITT PAD environment. They may not be updated,

but may be given initial content values during the

association establishment by special profile arguments

r4 and r5 . )*

CO -name = DTE,

CO- structure = 2,

CO-access = "no-access,"

{ *( Calling DTE address )*

co-element-id = 1,

co-category = "character,"

co-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 15 )

,

{ *( Called DTE address )*

co-element-id = 2,

co-category = "character,"

co-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 15 } }.

14-64
September 1990 (Stable)

{ *( FAC - This CO is used to optionally indicate the CCITT

facilities which are normally negotiable during the

establishment of a PAD virtual circuit. The

negotiation takes place in the VT association

establishment via special profile argument r6 , where

the initiator may propose the initial content value,

and the acceptor may return other values. )*

CO -name = FAC,

CO -structure = 1,

CO-access = "no-access,"

CO-category = "character,"

co-repertoire-assignment *(VTS Transparent Set )* = <ESC> 2/5 2/15 4/2,

co-size = 127

),

Device-objects *(double occurrence)* =

{

{device-name = DEVICE-1,

device-default-CO-access = profile-argument-rl

,

device-default-CO-priority = "normal,"

device-default-CO-trigger = "not-selected,"

device-default-CO- initial-value = l."true,"

device -minimum-X- array- length = 1, *(no constraint)*

device -control -object = { BI , BO, PAD ),

device-display-object = Dl

*( termination parameters are controlled explicitly

through the values assigned to elements 3 and 4 of the

PAD Control Object)*

).

{device-name = DEVICE-2,

device-default-CO-access = opposite of profile-argument-rl

,

device-default-CO-priority = "normal,"

device-default-CO-trigger = "not-selected,"

device-default-CO- initial-value = l."true,"

device -minimum-X- array- length = 1, *(no constraint)*

device-control-object = { READ, PAD ),

device-display-object = D2

) ).

Type of delivery control = " simple -de livery- control .
September 1990 (Stable)

14. 8 .4.4 Profile Arguments

rl - is mandatory, and is used to establish the access

rules for the display objects and several of the

control objects. This argument takes one of the values

"WACI" or "WACA." It is identified by the identifier

for DO-access for display object Dl

.

r2 - is an optional special profile argument, and is used

to set the intial content value of element 1 of the CUD

CO. The value is encoded from the binary form to the

ASN.l type PrintableString according to the algorithm

described in Definitive Note 24. This argument is

assigned the identifier "Pp-1."

r3 - is an optional special profile argument, and is used

to set the initial content value of element 2 of the

CUD CO. The value is encoded from the binary form to

the ASN.l type PrintableString according to the

algorithm described in Definitive Note 24. This

argument is assigned the identifier "Pp-2."

r4 - is an optional special profile argument, and is used

to set the initial content value of element 1 of the

DTE CO. The value is encoded from the binary form to

the ASN.l type PrintableString according to the

algorithm described in Definitive Note 24, This

argument is assigned the identifier "Pp-3."

r5 - is an optional special profile argument, and is used

to set the initial content value of element 2 of the

DTE CO. The value is encoded from the binary form to

the ASN.l type PrintableString according to the

algorithm described in Definitive Note 24. This

argument is assigned the identifier "Pp-4."

r6 - is an optional special profile argument, and is used

to set the initial content value of the FAC CO. The

value is encoded from the binary form to the ASN.l type

PrintableString according to the algorithm described in

Definitive Note 24. This argument is assigned the

identifier "Pp-5."

14-66
June 1990 Stable

14.8.4.5 Profile Notes

14.8.4.5.1 Definitive Notes

1. The value assigned to element 1 of PAD CO selects

the character used to return control to the

terminal -system. The valid values and associated

meanings are:

value meaning

0 not-permitted

1 1/0 character (DLE)

32-126 graphic character

2. The value assigned to element 2 of PAD CO

determines whether or not characters are echoed at

the terminal-system. When the value of this

boolean is "true," then the characters are echoed

at the terminal -system.

3. The values assigned to element 3 of PAD CO control

the forwarding of characters from the terminalsystem to the application- system based on the

character value. The defined booleans and

associated meanings are:

boolean meaning

1 alphanumeric (A-Z, a-z, 0-9)

2 character 0/13 (CR)

3 characters 1/11 (ESC), 0/7 (BEL), 0/5

(ENQ), 0/6 (ACK)

4 characters 7/15 (DEL) , 1/8 (CAN) , 1/2

(DC2)

5 characters 0/3 (ETX) , 0/4 (EOT)

6 characters 0/9 (HT) , 0/10 (LF) , 0/11

(VT), 0/12 (FF)

7 all others in column 0 and 1 not already

included above

4, The value assigned to element 4 of PAD CO controls

the forwarding of characters from the terminalsystem to the application-system based on the

duration of idle time elapsed between consecutive

characters received by the terminal -system from

the device. The valid values include any non- negative integer 0-255; a value between 1 and 255

indicates the time-out in twentieths of a second;

14-67
June 1990 Stable

a value of 0 means that a time-out is not a forwarding condition.

5. The value assigned to element 5 of PAD CO

determines whether the XON/XOFF flow-control

characters (1/1 and 1/3) are available for use by

the terminal -system. When the value of this

element is "true," then the flow-control

characters are available, and the terminal -system

may use them to indicate to the device its

readiness to accept characters from it,

6. The value assigned to element 6 of PAD CO

determines whether the terminal -system issues

messages, called PAD seirvice signals, to the

device during the association. The specific

service signals are not a part of this profile

definition, only the control of their issue,

7. The values assigned to element 7 of PAD CO

determine the behavior at the terminal-system when

a Break is received from the device. The defined

booleans and associated meanings are:

boolean meaning

1 update BO CO

2 release the association

3 update BI CO

4 return control to terminal-system

5 discard data from application- system

When all booleans have the value "false," there is no action at the terminal-system when a Break is

received

A useful combination of booleans with value "true"

is (1,3,5). When a Break is received. the

terminal -system updates both the BO CO and the BI

CO and discards all display-object updates from

the application-system until it receives an update

to the PAD CO for element 8. The result is that

the data path has been cleared in both directions.

Notice that this is non-destructive of control

object updates,

8. The value assigned to element 8 of PAD CO

determines whether or not the terminal -system

discards data from the application- system. This

element works with element 7 to acknowledge the

14-68
June 1990 Stable

receipt of the Break and resume normal processing

of display-object updates. The only valid value

of this boolean in an update is "false."

9. The value assigned to element 9 of PAD CO

indicates the number of padding characters to be

generated by the terminal -system to the device

following a carriage return character. The valid

values are integers in the range 0-7.

10. • The value assigned to element 10 of PAD CO

indicates the number of graphic characters sent to

the device after which the terminal- system will

insert a carriage return. The valid values are integers in the range 0-255, where a value of 0

means that this function is not performed.

11. The value assigned to element 11 of PAD CO

indicates the bit- transmission speed of the

device. This element may only appear in an update

sent to the application-system in response to an update of the READ CO when boolean 11 has the

value "true."

12. The value assigned to element 12 of PAD CO

determines whether the XON/XOFF flow-control

characters (1/1 and 1/3) are available for use by

the device. When the value of this element is

"true," then the flow-control characters are available, and the device may use them to indicate

to the terminal -system its readiness to accept

characters from it.

13. The values assigned to element 13 of PAD CO

determine under which situations a linefeed is

inserted following a carriage return character.

The valid values and associated meanings are:

boolean meaning

1 insert linefeed after carriage

return sent to device

2 insert linefeed after carriage

return received from device

3 insert linefeed after carriage

return echoed to the device

14. The values assigned to element 14 of PAD CO

determine the number of padding characters

generated by the terminal -system to the device

14-69
June 1990 Stable

following a linefeed character. The valid values

are any number in the range 0-7.

15. The value assigned to element 15 of PAD CO

determines whether or not the terminal -system

performs data-editing. When this CO has value

"true," the values of the elements 3 and 4 of the

PAD CO are ignored.

16. The value assigned to element 16 of PAD CO

determines which character is used in editing the

line to signify the function "delete character."

The valid values are the IA5 characters, decimal

value 0-127. Only applicable if the value of

element 15 of PAD CO is "true."

17. The value assigned to element 17 of PAD CO

determines which character is used in editing to

signify the function "delete line." The valid

values are the IA5 characters, decimal value 0-

127. Only applicable if the value of element 15

of PAD CO is "true."

18. The value assigned to element 18 of PAD CO

determines which character is used in editing to

signify the function "display line." The valid

values are the IA5 characters, decimal value 0-

127. Only applicable if the value of element 15

of PAD CO is "true."

19. The value assigned to element 19 of PAD CO

determines whether the terminal-system provides

for editing of PAD service signals. The valid

values and meanings are as follows:

value meaning

0 no editing

1 editing as for a paper device

2 editing as for a glass device

8 editing using one editing character

32-126 editing using one editing character

14-70
June 1990 Stable

20. The values assigned to element 19 of PAD CO

determines which characters are NOT to be echoed

to the device by the terminal -system. If no bits

are set, then all characters are to be echoed,

assuming that element 2 has the value "true." The

defined booleans and associated meanings are:

boolean meaning

1 ^ Do not echo 0/13 (CR)

2 Do not echo 0/10 (LF)

3 Do not echo 0/11 (VT) , 0/9 (HT)

0/12 (FF)

4 Do not echo 0/7 (BEL) or 0/8 (BS)

5 Do not echo 1/11 (ESC) or 0/5 (ENQ)

6 Do not echo 0/6 (ACK) , 1/5 (NAK)

,

0/2 (STX), 0/1 (SOH), 0/4 (EOT),

1/7 (ETB) or 0/3 (ETX)

7 Do not echo the editing characters

defined by elements 16, 17 and 18

of the PAD CO

8 Do not echo 7/15 (DEL) or any of

the other characters belonging to

CO or CI which are not already

mentioned above

21. The value assigned to element 21 of PAD CO

determines the treatment of parity on the

characters received from and sent to the device

from the terminal-system. The defined booleans

and associated meanings are:

boolean meaning

1 parity is checked on characters

received from the device

2 parity is generated on characters

sent to the device

22. The value assigned to element 22 of PAD CO

determines the number of linefeeds that the

terminal -system may send to the device before it

must wait for input from the device request it to

continue displaying characters. The range of

valid values is 0-255, where a value of 0

indicates that the terminal-system need never

wait

.

23. The text operation is the only operation allowed

on the display objects.

14-71
June 1990 Stable

24. Special profile arguments r2-r6 have binary

values. However, due to a restriction in the

standards 9040 and 9041 , those binary values must

be conveyed in the ASN.l type PrintableString.

This is accomplished by mapping the value of each

semi-octet in the string of binary octets to an

octet whose value falls in the value range of a PrintableString. The semi-octet values in the

range 0000 - 1001 are mapped into the

PrintableString values '0' - '9', whereas the

semi-octet values in the range 1010 - 1111 are mapped into the PrintableString values 'A' - 'F'.

The result is a string of characters which is

exactly twice the length of the original string of

binary octets.

25. The value of CO-access for the PAD CO is "NSAC,"

however a convention is followed that determines

when a VT-user may update the PAD CO. Only the

VT-user with access to the Display Object D2 may

update the PAD CO except immediately after it has

updated the READ CO. When the READ CO is received

by the opposite VT-user, it is treated as a request to update the PAD CO with the parameter

values it is currently using, at which point that

VT-user is required to respond.

14-72
June 1990 Stable

14. 8 .4. 5

2

Informative Notes

Users of this profile should refer to CCITT

Recommendations X.3, X.28 and X.29 for the

original model for this profile.

!. The following values for the elements of the PAD

CO are taken from the CCITT Simple standard

profile and may prove useful:

element- id Value

possible to return

control to the terminal

system using 0/1 (DLE)

2 l."true"

echo performed at the

terminal -system

3 1. "false," 2. "true," 3. "true,"

4. "true," 5. "true," 6. "true,"

7. "true"

forward on receipt of any

character in CO and CI

4 0 no time-out used for

forwarding condition

5 l."true"

terminal-system use XON/XOFF to flow- control

the device

6 l."true"

service signals are sent

7 2. "true," all others "false"

release the association

when a Break is received

from the device

8 1. "false"

deliver data to device

9

do not pad after CR

14-73
June 1990 Stable

10 0

do not fold the line

11 - read-only

12 l."true"

device use XON/XOFF to

flow- control the

terminal - sys tem

13 0

do not insert LF after CR

14 0

do not pad after LF

15 1. "false"

do not edit data

16 7/15 (DEL)

character delete

17 1/8 (CAN)

line delete

18 1/2 (DC2)

line display

19 1

20 0

21 0

22

edit as for paper

echo all characters

no parity checking or generation

no page wait

The following values for the elements of the PAD

CO are taken from the CCITT Transparent standard

profile and may prove useful,

element- id Value

1 0

control may not be

returned to the terminal

system

2 1. "false"

the terminal -system does

not perform character

echo

3 all booleans "false"

no forwarding on character value

4 20

forward on time-out of 1 second

14-74
June 1990 Stable

5 1. "false"

terminal-system may not

flow-control device

6 1. "false"

service signals are never

sent

7 2. "true," all others "false"

release the association

8 1. "false"

deliver data to device

9 0 no pad after CR

10 0 no line folding

11 - read-only

12 1." false"

device may not flowcontrol terminal -system

13 0 no LF insert after CR

14 0 no pad after LF

15 1. "false"

no editing data

16 7/15 (DEL)

character delete

17 1/8 (CAN)

line delete

18 1/2 (DC2)

line display

19 1

20 0

21 0

22

edit as for paper

echo all characters

no parity checking or generation

no page wait

14 8 . 4 . 6 Specific Conformance Requirements

None

.

14-75
June 1990 Stable

14.9 APPENDIX A

14. 9 . 1 Specific ASE Requirement

For specific ASE Requirements identified by the Upper Layer SIG

for Virtual Terminals, see chapter 5, entitled "Upper Layers" in

this document.

14.10 APPENDIX B - CLARIFICATIONS

14. 10. 1 Defaults

When a profile argument is not present in either the offer or value list, the default for the corresponding VTE parameter is

specified by ISO 9040 if it is not given by the argument

description in the profile.

14. 11 APPENDIX C - OBJECT IDENTIFIERS

General identifiers

:

oiw-vt OBJECT IDENTIFIER : :=

{ iso(l) identified-organization(3) oiw(14) vtsig(12) }

oiw-vt-pr OBJECT IDENTIFIER : :=

{ oiw-vt vteProfile(l) }

oiw-vt-co OBJECT IDENTIFIER : :=

{ oiw-vt controlObj ect (0) }

oiw-vt-co-misc OBJECT IDENTIFIER : :=

{ oiw-vt-co cotypemisc(O) }

oiw-vt-co-tcco OBJECT IDENTIFIER : :=

{ oiw-vt-co cotypetcco(4) }

Profile defined by OIW VT SIG:

oiw-vt-pr-telnet-1988 OBJECT IDENTIFIER

{ oiw-vt-pr telnet-1988(0) )

oiw-vt-pr- transparent- 1988 OBJECT IDENTIFIER

{ oiw-vt-pr transparent- 1988(1) ) oiw-vt-pr-forms-1989 OBJECT IDENTIFIER

{ oiw-vt-pr forms-1989(2) )

14-76
oiw-vt-pr-x3-1989 OBJECT IDENTIFIER

{ oiw-vt-pr x3-1989(4) )

Control Objects defined by OIW VT SIG:

oiw-vt-co-misc-sa OBJECT IDENTIFIER

{ oiw-vt-co-misc sa(0) )

oiw-vt-co-misc-ua OBJECT IDENTIFIER

{ oiw-vt-co-misc ua(l) )

oiw-vt-co-misc-st OBJECT IDENTIFIER

{ oiw-vt-co-misc st(2) }

oiw-vt-co-misc-ut OBJECT IDENTIFIER

{ oiw-vt-co-misc ut(3) )

14-77

June 1990 Stable

TRANSACTION PROCESSING

Editor's Note: This section is a placeholder for future

Transaction Processing (TP) Agreements. The -TP

Special - interes-t- -Group - is- -newly- - ferned- -and- -held

its -first -regular -meeting -in -March ,--19897 Any new

text from this group will be inserted here.

15-1

December '89

16. OFFICE DOCUMENT ARCHITECTURE

Editor's Note: There is international alignment work taking place

which is likely to produce an International

Standardized Profile (ISP) corresponding to the

level of ODA functionality being addressed by

these agreements. The Plenary, in December 1989,

approved a resolution that this DAP should be

superseded by the equivalent internationally

aligned ODA DAP when it is submitted for

processing as an ISP. The intent is to rename

this chapter "OFFICE DOCUMENT ARCHITECTURE LEVEL 3 DAP." The contents herein were last modified by

the Plenary in June 1989.

16. 1 INTRODUCTION

This is the definition of an ODA document application profile ( AP)

named NIST Level 3 DAP. The NIST Level 3 DAP is suitable for

interchanging a document in formatted form, processable form or formatted processable form. This DAP has been prepared by the ODA

Special Interest Group of the National Institute of Standards and

Technology (NIST) Workshop for Implementors of OSI. The DAP is

defined in accordance with ISO 8613-1 and CCITT T.411 and follows the

standardized proforma and notation defined in ISO 8613-1 proposed

Draft Addendum (to be published).

Note: The agreements defining this ODA DAP will be

superseded by the equivalent internationally aligned

ODA DAP when it is submitted for processing as an International Standardized Profile (ISP).

16.2 SCOPE AND FIELD OF APPLICATION

This DAP specifies interchange formats for the transfer of structured

documents between equipment designed for word or document processing.

Such documents may contain characters, raster graphics and geometric

graphics content.

The documents supported by this profile range from simple documents to

highly structured technical reports, articles and typeset documents

such as brochures. This profile provides a comprehensive level of

features for the transfer of documents between these systems.

This document application profile describes documents which can be

interchanged in the following form, as defined in ISO 8613:

Formatted form,

16-1
December '89

Processable form, and

Formatted processable form.

The architecture level have matching functionalities so that the

interchange formats of a document are convertible from a processable

form into any other form.

This DAP is independent of the processes carried out in an end system

to create, edit or reproduce which, for example, may be by means of

communication links or storage media.

16.3 REFERENCES

ISO 2022 Information Processing - ISO 7-bit and 8-bit coded character

sets - Code extension techniques

ISO 6937-1 Information Processing - Coded character sets for text

communication - Part 1 : General introduction

ISO 6937-2 Information Processing - Coded character sets for text

communication - Part 2: Latin alphabetic and non-alphabetic graphic

characters

ISO 8613-1 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 1

:

Introduction and General Principles

ISO 8613-2 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 2: Document

Structures

ISO 8613-4 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 4: Document

Profile

ISO 8613-5 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 5: Office

Document Interchange Format

ISO 8613-6 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 6: Character

Content Architecture

ISO 8613-7 Information Processing - Text and Office Systems - Office

Document Architecture (ODA) and Interchange Format - Part 7: Raster

Graphics Content Architecture

ISO 8613-8 Information Processing - Text and Office Systems - Office

16-2
December ' 89

Document Architecture (ODA) and Interchange Format - Part 8: Geometric

Graphics Content Architecture

ISO 8613-1 PDAD . . . "Document Application Profile Proforma and

Notation" (to be published)

ISO 8632-1 Information Processing Systems - Computer Graphics - Metafile for the storage and transfer of picture description

information - Part 1 : Functional Specification

ISO 8632-3 Information Processing Systems - Computer Graphics - Metafile for the storage and transfer of picture description

information - Part 3 : Binary Encoding

ISO 8859-1 Information Processing - 8 -bit single byte coded graphic

character sets - Part 1: Latin Alphabet No. 1

ISO 8859-7 Information Processing - 8-bit single byte coded graphic

character sets - Part 7 : Latin/Greek Alphabet

ISO 8824 Information Processing Systems - Open Systems Interconnection

- Specification of Abstract Syntax Notation 1 (ASN.l)

ISO 8825 Information Processing Systems - Open Systems Interconnection

- Specification of Basic Encoding Rules for Abstract Syntax Notation 1 (ASN. 1)

CCITT T.6 - Facsimile coding scheme and coding control functions for

Group 4 Facsimile Apparatus, 1984

CCITT T.411 Open Document Architecture (ODA) and Interchange Format - Introduction and general principles, 1988

CCITT T.502 Document Application Profile PM.l for the interchange of

processable form documents

PrENV ... QUI ODA document application profile - processable and

formatted documents - basic character content (to be published)

PrENV . . . Q112 ODA document application profile - processable and

formatted documents - extend mixed mode (to be published)

INTAP ... AE-1126 ODA document application profile ...

PAGODA . . . CORE- 11 ODA document application profile - processable and

formatted documents - basic character content (to be published)

PAGODA . . . CORE-26 ODA document application profile - processable and

formatted documents - advanced mixed mode (to be published)

16-3
December '89

PAGODA . . . Core-36 ODA document application profile - processable and

formatted document - enhanced mixed mode (to be published)

16.4 DEFINITIONS AND ABBREVIATIONS

The definitions given in ISO 8613-1 are applicable to this document.

The following additional definitions are applicable to this document.

Generating Support Statement (GSS)

A statement which states the range of support of an originating

system. An originating system generates ODIF data streams. A

GSS defines a subset of all possible data streams supported by an implementation which an origination capability. A GSS is

specified by completing the GSSP defined in Annex A of this

document

.

Generating Support Statement Proforma (GSSP)

A definition of the conformance requirements of a profile in

terms of a list of requirements for implementations to originate

data streams which conform to the profile. A GSSP defines the

format for all GSSs.

Implementation Characteristic Statement (ICS)

A statement which states the range of support of an implementation to a DAP.

Receiving Support Statement (RSS)

A statement which states the range of support of a receiving

system. A receiving system interprets ODIF data streams. A RSS

defines functions and fall-backs supported by an implementation

with a reception capability, A RSS is specified by completing

the RSSP defined in Annex A of this document.

Receiving Support Statement Proforma (RSSP)

A definition of the conformance requirements of a profile in

terms of a list of requirements, including fall-backs, for

implementations to receive data streams which conform to the

profile. A RSSP defines the format for all RSSs.

16-4
December '89

16.5 POSITION OF THIS DAP IN THE TAXONOMY OF RELATED DAPS

There is only one DAP currently being developed by the NIST ODA SIG.

This DAP is a Level 3 DAP, in relation to the following hierarchy.

Level 1 Basic documents consisting of character content only.

This level of document contains the functionality found

in most word processor products.

Level 2 Extended dociaments consisting of character, raster

graphics and geometric graphics content. This level of

document contains enhanced functionality to support

multi-media document processors evolved from word

processor precursors.

Level 3 Advanced documents consisting of character, raster

graphics and geometric graphics content. This level of

docioment contains the functionality traditionally found

in most "desktop publishing" or personal publishing

products

.

16.6 CONFORMANCE

In order to conform to this DAP, a data stream representing a document

must meet the requirements specified in clause 16.5.1.

Clause 16.5.2 specifies the requirements for implementations that

originate and/or receive data streams conforming to this DAP.

16.6.1 Data stream conformance

The following requirements apply to the encoding of data streams

that conform to this ISP.

The data stream shall be encoded in accordance with the

ASN.l encoding rules defined in ISO 8825,

The data stream shall be structured in accordance with

the interchange format defined in clause 16.8 of this

DAP,

The encoded document shall be structured in accordance

with one of the document architecture classes specified

in clause 16.7 of this DAP. In addition, the encoded

document shall contain all required constituents

specified for that class and contain only constituents

permitted or required for that class as specified in

clause 16.7 of this DAP,

16-5
December ' 89

The encoded constituents shall contain all required

attributes as specified in clause 16.7 of this DAP,

The encoded attributes shall have values within the

range of permissible values specified in clause 16.7 of

this DAP,

The encoded document shall be structured in accordance

with the abstract document architecture defined in ISO

8613,

The encoded document shall be structured in accordance

with the characteristics defined in clause 16.6 of this

DAP.

16.6.2 Implementation conformance

This clause states the requirements for implementations claiming

conformance to this DAP.

An implementation claiming to originate and/or receive data

streams conforming to this DAP must complete a Generator Support

Statement (GSS) and/or Receiver Support Statement (RSS) Proforma

as defined in Annex A of this DAP.

A conforming receiving implementation must be capable of

receiving any data stream conforming to this DAP. "Receiving" means not rejecting a data stream conforming to this DAP and

usually, but not always, involves recognizing and further

processing the data stream elements. The explicit meaning of

"receiving" is determined by a RSS defined in accordance with

Annex A of this DAP.

16.7 CHARACTERISTICS SUPPORTED BY THIS DAP

16.7.1 Overview

The NIST Level 3 DAP, in accordance with ISO 8613, allows

documents to be represented in the following forms:

processable form, which facilitates the revision of a document by a recipient;

formatted form, which facilities the reproduction of a document as intended by the originator;

formatted processable form, which facilitates the

16-6
December '89

reproduction of a document as intended by the

originator or facilitates the revision of a document.

16.7.1.1 Specification of constituents

This section specifies the required and optional

constituents used for the representation of documents that

conform to the NIST Level 3 DAP.

Constituents specified as 'required' must occur in any

document that conforms to the NIST Level 3 DAP.

Constituents listed as 'optional' may or may not be present

in the document depending upon the requirements of the

particular document.

16.7.1.2 Formatted form documents

Required Constituents

a document profile

layout object descriptions representing a specific

layout structure

Optional Constituents

layout object class descriptions representing a 'partial' generic layout structure

presentation styles

16.7.1.3 Processable Form Documents

Required Constituents

a document profile

logical object class descriptions representing a 'complete' generic logical structure

logical object descriptions representing a specific logical structure

Optional Constituents

layout object class descriptions representing a 'complete' generic layout structure

16-7
December '89

layout styles

presentation styles

16.7.1.4 Formatted Processable Form Docioments

Required Constituents

a document profile

logical object class descriptions representing a 'complete' generic logical structure

logical object descriptions representing a specific logical structure

layout object class descriptions representing a 'complete' generic layout structure

layout object descriptions representing a specific

layout structure

Optional Constituents

layout styles

presentation styles

The following sections describe the logical and layout

features that can be represented in documents conforming to

this document application profile. The features are described in terms that are typical of the capabilities of

current document processors . The features are grouped into

logical features and layout features in order to relate them

to their ODA representation.

Documents conforming to this document application profile

may contain any or all of the following content

architectures

:

a) character text,

b) raster graphics, and

c) geometric graphics.

.7.2 Logical characteristics

16-8
December '89

16 . 7 2 1 Document logical structure

The logical structure of documents comprise a title,

passages, numbered segments (e.g., chapters, sections or numbered paragraphs), paragraphs, phrases, figures,

footnotes and references. Numbered segments can be nested

and automatic numbering systems are provided for.

The logical structure of a document conforming to this

document application profile consists of a hierarchy of

logical objects. The following is an example of a generic

document logical structure derived from this document

application profile:

Document

Passage (s)

Paragraph

Text

Footnote

Footnote reference

Footnote body

Text

Figure

Text

Figure

Numbered Segment

Number

Title

Passage

Paragraph

Figure

Numbered Segment

16.7.2.2 Document structure elements

16 . 7 . 2 2 1 Document

A document is composed of a sequence of numbered

segments or passages each of which is optionally titled

and consists of a sequence of paragraphs and/or figures

and/or further passages or numbered segments

.

16.7.2.2.2 Passage

A passage consists of any logical sequence of

paragraphs, figures, and/or further passages or

16-9
December '89

numbered segments that can be regarded as an entity for

reading or for layout presentation.

For example, separate passages may be provided for:

a) the contents to be placed on the title page

of a report,

b) the body of the report, and

c) the contents to be placed In appendices,

A table is a particular case of a passage. A single

paragraph or a single figure is a simple case of a passage

.

16.7.2.2.3 Numbered Segment

A segment is a part of a document which has an automatic number which precedes any other contents and

which serves to uniquely identify the numbered segment.

The contents of a numbered segment may begin with a segment title starting on the same line as the segment

number

.

The document originator may define different classes of

numbered segments having in common some presentation

features and/or some layout features. For example, the

document originator may define a class of numbered

segments which always begin on a new page, and another

class of numbered segments which are laid out using a special left or right margin offset.

An automatically generated segment number consists of

either a number or a series of numbers separated by

instances of an arbitrary specified character string

separator. In the case of a series of numbers, the

segment number is equal to the automatically generated

segment number, if any, of the enclosing segment

followed by a single index number to uniquely identify

the segment.

Index numbers are generated sequentially within any

numbered segment. The method of numbering may be a combination of the following:

a) Arabic numerals,

b) Upper/lower case letters, or

c) Upper/lower case Roman numerals.

16-10
December '89

16.7.2. 2.

4

Paragraph

A paragraph is a contiguous amount of content in the

intended reading order. For example, a paragraph may

contain a mixture of embedded phrases , figures

,

footnote references and character text.

A paragraph may contain zero, one or more embedded

phrases

.

A paragraph may contain zero, one or more embedded

figures and, optionally, figure references. Multiple

consecutive figures and/or figure references, without

intervening text, are permitted.

A paragraph may contain zero, one or more embedded

footnote references . Multiple consecutive footnote

references, without intervening text, are also

permitted.

A paragraph may comprise a numiber of character

sequences concatenated together, for example if the

character sequences were separately derived or generated

.

The document originator may define different classes of

paragraphs having in common some presentation features

and/or some layout features. For example, the document

originator may define classes of paragraphs for

"abstract," "standard paragraph," and "summary."

16.7.2.2.5 Phrase

A phrase is an amount of text content that is intended

to be distinguished. The phrase can be used to

construct a paragraph containing sections of text with

different presentation features. For example, in the

midst of a paragraph a phrase may be highlighted to

distinguish a quote.

A phrase can consist of one or more text content,

references, footnotes or other phrases.

16.7.2.2.6 Figure

16-11
December '89

A figure is an amount of geometric graphics or raster

graphics content designed to occupy a rectangular area.

One or more paragraphs can be associated with a figure,

for example to provide captions or notes.

A footnote consists of a footnote reference and a footnote body.

The footnote body is a contiguous amount of text that can be read out of sequence from the paragraph

containing a reference to it.

16.7.2.2.8 Footnote reference

A footnote reference may have an automatically

generated label or one supplied by the user. (Both

types of footnote references may be present.) If the

label is automatically generated then the label may be

represented by Arabic numerals, upper or lower case Roman numerals, or upper or lower case alphabetic

characters

.

Automatically generated footnote numbers are incremented sequentially from an initial value which

may be set to any non-negative value at the beginning

of the document and reset at any segment or passage, as required.

A general purpose reference mechanism is provided

within paragraph. For example, this reference may be

used to reference figures, page numbers, chapter

numbers, etc. in other parts of the document.

16.7.2.2.7 Footnote

16.7.2.2.9 Reference

16.7.3 Layout characteristics

16-12
December '89

16.7.3.1 Document layout structure

The page layout structure allows for several pagesets

(e.g., for title page, foreword and annexes in addition to

the main text body, which could be in chapters or sections)

The body area of a page may contain multiple columns and areas for graphics. Header and footer contents can also

inc lude fi gure s

.

The following is an example of a generic document layout

structure derived from this document application profile:

Document

Page set

Page

Header area Body area

Single frame

Multiple columns

Individual frame (s)

Mixed set of frames

Footer area

16.7.3.2 Document layout structure elements

16.7.3.2.1 Document

A document consists of a sequence of one or more page

sets

.

16.7.3.2.2 Page set

The pages within a page set all have the same dimensions and orientation (landscape or portrait) but

may differ in layout and/or content of the header and

footer areas.

There may be an optional first page of one particular

page layout and this may be followed by either of the

following:

a) Repeated pages with the same layout

b) Repeated pages designed for alternating recto

and verso layout

16-13
December ' 89

16.7.3.2.3 Page layout

This document application profile supports various page

dimensions. The default dimensions is the common

assured reproduction area of ISO A4 and North American

Letter. In addition, support is provided for the

assured reproduction area of ISO A4 and North American

Letter, as well as, the full page dimensions of ISO A4

and North American Letter. Both portrait and landscape

orientations are supported.

A page layout consists of:

a) An optional header area that is reserved for

header contents,

b) A single body area, or

c) An optional footer area that is reserved for

footer contents.

Particular header and footer contents are associated

with each page layout

.

16.7.3.2.4 Body area layout

The body area may be subdivided into rectangular

frames. Thus the layout may consist of any sequence

of:

a) Single frame of fixed width, equal or less

than body area width, and fixed height or height adjustable to fit contents,

b) Set of multiple column frames of fixed widths

per column and fixed height or height

adjustable to fit contents,

c) Individual frames with fixed position and

dimensions, potentially overlaid, allowing

for support of forms,

d) Mixed set of frames with various properties,

e.g., fixed-size figure frame with

fixed-sized caption frame beneath and

adjustable height text frame beside both.

See figure 16.1 for illustrations.

Frames which have fixed position and dimensions are permitted to overlap.

16-14
December ' 89

16 . 7 . 3 2

5

Header area layout

This is a rectangular area above the body area. It

be subdivided into a number of rectangular frames, f

example to contain textual information and graphics

such as company logos

.

16-15
December '89

Body Area

(a) single frame

(b) multiple columns

(c) individual frames

(d) mixed set of frames

Figure 16.1. Examples of layout within body area.

16.7.3.2.6 Footer area layout

This is a rectangular area below the body area. It may

be sub-divided into a number of rectangular frames, for

example to contain textual information and graphics

such as company logos

.

16-16
16.7.3.2.7

December '89

Header contents and footer contents

Header contents or footer contents may consist of a sequence of paragraphs and/or figures that are constrained to be laid out entirely within the

corresponding header or footer area.

One or more automatically generated page numbers may be

included anywhere within header contents and/or footer

contents

.

Header contents or footer contents must not include any

footnote or footnote reference or automatic segment

numbers

.

16.7.3.2.8 Page numbering

An automatically generated page number may occur at any

position within header contents or footer contents.

Page numbers may represented in Arabic numerals,

lower/upper case Roman numerals or lower/upper case letters

.

Page numbers are generated sequentially and the

sequence can be restarted from any positive integer

value at the beginning of any page set.

16.7.3.2.9 Layout of document logical contents

The sequence of passages and/or segments is laid out in one or more body areas such that it flows through the

sequence of pages in the document.

Controls are needed in order to break the flow of

contents at appropriate points. For example, following

the passages to be placed on the title page of a document it may be required to control the flow in

order to direct subsequent text onto a new page of a different page layout.

16.7.3.2.10 Layout of passage (or segment) contents

A passage may be laid out in any of the following ways:

As separate passages (see below)

,

Below the previous text within a containing

passage, or

a)

b)

16-17
December '89

c) As a sequence of passages

.

16.7.3.2.11 Layout of passage contents

Controls are available to guide the layout of passages

or their subordinate paragraphs and figures.

A passage can be positioned at a fixed position (e.g.,

the start) of a new body area or in a new frame below

the previous contents of a body area.

In case of sets of multiple columns, content generally

flows from the bottom of one column of the set to the

top of the next column to the right.

Regardless of content type , the various paragraphs and

figures in a passage may be laid out within specified

frames

.

The various methods of subdivision of body areas may be

combined with certain frames being designated for

flowing text and other frames for particular contents.

Thus text may appear to flow around other contents.

For example, several figures can be contained within a passage and effect of text flow around the figures and

their captions can be produced. See figure 16.2 for

illustration.

A new set of multiple frames can occur beneath a similar set. Thus parallel text (e.g., multilingual)

can be synchronized or a table effect can be generated.

See figure 16.3 for illustration.

A variation of the table technique can be used for

labelling and annotating paragraphs.

A complete passage can be constrained to be contained

in the same body area or frame (by indivisibility)

.

16.7.3.2.12 Layout controls

The following properties may be specified to control

where body area or page breaks occur:

a) New column set (New Layout Object)

This specifies that the contents should be laid out in

16-18
December '89

the first column (or frame) of a new set of columns (or

frames)

.

b) Unconditional column break (New Layout

Object)

This indicates that the contents must be displayed in

the next column (or frame)

.

Body Area

text

notes

caption

- text —

continued

- text —

continued

Figure 16.2. Example of text flow around figura

Note: "Caption" and "Notes" contain formatted

character content.

16-19
Body Area

December '89

Figure 16.3. Example of synchronized text.

c) Layout object class

This indicates that the contents concerned must be

displayed in a specified frame, e.g., to control

figure positioning.

d) New page set (New Layout Object)

This indicates that the contents should be laid out in

a new page set.

e) New page layout (New Layout Object)

This indicates that the contents should be laid out on

a new page of a particular page layout.

16-20
December '89

f) Unconditional page break (New Layout Object)

This indicates that the contents must be displayed in

the body area of the next page.

g) Indivisibility

This indicates that a passage (segment, paragraph or figure) must be laid out within a single frame, body

area or page set.

h) Same page/same area (Same Layout Object)

This specifies that the start of a passage, numbered

segment, paragraph, or figure, for example, must be

laid out in the same frame or body area as the end of

the previous content (for example, to keep a first

paragraph with a title)

16.7.3.2.13 Layout of paragraph contents

A paragraph may or may not specify its own margins,

alignment and tab stops. The indentation of the first

line may be different from the remainder of the

paragraph. The separation between successive

paragraphs can be controlled.

Within a passage the contents of a paragraph may be

laid out in two or more frames to allow text to flow

around a figure. The figure may or may not be

logically associated with that paragraph.

By using the widow and orphan features, layout of

paragraphs can also be controlled in order to determine

how a paragraph should be divided across two pages.

The orphan size specifies the minimum number of lines

of text that must be allocated to the first body area

or frame

.

The widow size specifies the minimum number of lines of

text that must be allocated to the last body area or frame when a paragraph is split over two or more body

areas or frames.

16.7.3.2.14 Layout of figure contents

16-21
December '89

A figure may occur beneath the previous contents of a body area or frame or can be specified to occupy a particular frame.

Any paragraphs associated with the figure, for example,

to provide captions or notes, can be positioned to

occupy rectangular areas positioned above, below or beside the figure.

16.7.3.2.15 Layout of footnote contents

A footnote body may be placed at the bottom of a body

area of a page and may or may not be constrained to be

entirely in the same body area as the reference to it.

If multiple footnotes occur in the same body area the

corresponding footnote bodies can be placed in the body

area in the same order as the reading order of their

references.

16.7.4 Content characteristics

A document may contain any of the following types of content:

a) Character text utilizing graphic characters as defined

in ISO 6937 and ISO 8859 together with character

presentation techniques defined in ISO 8613-6,

b) Raster graphics images encoded according to CCITT

Recommendations T.4 and T.6 and in unencoded bitmap

form,

c) Geometric graphics images in accordance with the

minimum capabilities of ISO 8632, each figure

consisting of a single picture only.

16.7.4.1 Character content

The document may contain character content portions as specified in ISO 8613-6.

16.7.4.1.1 Character repertoire

The character sets supported by this DAP include ISO

6937-2, ISO 8859-1 and ISO 8859-7.

16-22
December '89

The character subrepertoires of ISO 6937-2 supported by

this DAP include the:

Minimum subrepertoire (2)

,

Subrepertoire of graphic character for

teletex (3)

,

Unique grapics characters allocated to ISO

646 (5), and

Western European data processing and

interchange or ISO 8859-1 (8).

16.7.4.1.2 Character presentation

Character presentation is controlled by the

presentation attributes specified in ISO 8613-6.

Fonts may be specified and selected at any point in the

text. Up to ten different fonts can be selected within

a given portion of content.

16.7.4.1.3 Character set features and

control functions

The effects of graphic rendition can be changed at any

point within the text of a paragraph.

Sequences of characters within a piece of contiguous

text may be subscripted or superscripted.

Text can be aligned with specific tabulation stops.

Text strings and their justification can be terminated

by a required newline and can be word-wrapped within

the paragraph margins

.

Non-breaking spaces and discretionary hyphens are supported in processable and formatted processable form

content.

16.7.4.2 Raster graphics content

The document may contain raster graphics or image content

portions as specified in ISO 8613-7.

16.7.4.3 Geometric graphics content

16-23
December '89

The document may contain geometric graphics content portions

as specified in ISO 8613-8.

16.7.5 Miscellaneous features

16.7.5.1 Resources

Structure components (generic or specific logical or layout)

as well as content portions (character, raster or geometric

graphics) of documents may be located in "resource" document

external to a particular document.

16.7.6 Document management features

A document profile is associated with the document to provide

information to handle it as a whole.

The features specified by the document profile may contain those

document management attributes defined in ISO 8613 part 4.

Document profile character sets may use ISO 6937-2 or ISO 8859-1.

16.8 SPECIFICATION OF CONSTITUENT CONSTRAINTS

16.8.1 Document profile

16.8.1.1 Macro Definitions

DEFINE ( CHAR- S ET - LI ST

,

-- ISO 8859- 1 Primary Set as GO -- {2/8 4/2, LSO) 1 -- ISO 8859- 1 Supplementary Set as G2

{2/14 4/1, LS2R} 1 -- ISO 6937- 2 Primary Set as GO -- {2/8 4/0, LSO} 1 -- ISO 6937- 2 Supplementary Set as G2

{2/14 4/10, LS2R)

-- ISO 8859- 7 Supplementary Set as G2

{2/14 4/12, LS2R) ")

DEFINE ( NON - BAS IC - PAG - DIM

,

tl -- Assured Reproduction Areas --

-- Common North American Letter And ISO A4 Landscape --

16-24
#horizontal <= 12400, #vertical <= 9240,

North American Letter Landscape -- #horizontal <= 13200, #vertical <= 9240,

North American Legal Portrait -- #horizontal <= 9240, #vertical <= 12400,

North American Legal Landscape -- #horizontal <= 12400, #vertical <= 9240,

ANSI B Portrait -- #horizontal <= 12520, #vertical <= 19560,

ANSI B Landscape -- #horizontal <= 19560, #vertical <= 12520,

ISO A4 Landscape -- #horizontal <= 13200, #vertical <= 9240,

ISO A3 Portrait -- #horizontal <= 13200, #vertical <= 18480,

ISO A3 Landscape

#horizontal <= 18480, #vertical <= 13200,

ISO A2 Portrait -- #horizontal <= 18480, #vertical <= 26040,

ISO Al Portrait -- #horizontal <= 26040, #vertical <= 36960,

ISO AO Portrait -- #horizontal <= 36960, #vertical <= 52080,

Full Page Sizes --

-- North American Letter Portrait -- #horizontal <= 10200, #vertical <= 13200,

-- North American Letter Landscape -- #horizontal <= 13200, #vertical <= 10200,

-- North American Legal Portrait -- #horizontal <= 10200, #vertical <= 16800,

-- North American Legal Landscape -- #horizontal <= 16800, #vertical <= 10200,

-- ANSI B Portrait -- #horizontal <= 13200, #vertical <= 20400,

-- ANSI B Landscape -- #horizontal <= 20400, #vertical <= 13200,

-- ISO A4 Portrait -- #horizontal <= 9920, #vertical <= 14030,

-- ISO A4 Landscape -- #horizontal <= 14030, #vertical <= 9920,

-- ISO A3 Portrait -- #horizontal <= 14030, #vertical <= 19840,

-- ISO A3 Portrait -- #horizontal <= 19840, #vertical <= 14030

DEFINE(NON-BASIC-NOM-PAG-SIZ,

-- North American Letter Landscape --

16-25
#horizontal <= 13200,

North American Legal

#horizontal <= 10200,

North American Legal

#horizontal <= 16800,

ANSI B Portrait -- #horizontal <= 13200,

ANSI B Landscape -- #horizontal <= 20400,

ISO A4 Landscape -- #horizontal <= 14030,

ISO A3 Portrait -- #horizontal <= 14030,

ISO A3 Landscape -- #horizontal <= 19840,

#vertical <= Portrait -- #vertical <= Landscape - - #vertical <=

#vertical <=

#vertical <=

#vertical

#vertical <=

#vertical <=

10200,

16800,

10200,

20400,

13200,

9920,

19840,

14030 ")

DEFINE (FDA," 0")

DEFINE (PDA," 1")

DEFINE ( FPDA, " 2")

DEFINE ( DAC,

Document-profile {#Document-characteristics

{#Document-architecture-class )

) "

)

DEFINE ( CF,

{2 8 2 6 0) ")

DEFINE (CP," {2 8 2 6 1) ")

DEFINE ( CFP,

{2 8 2 6 2) ")

DEFINE (RFP,

[2 8 2 7 2} ")

DEFINE(GFP,

{2 8 2 8 0} ")

DEFINE (PARTIAL,

0")

DEFINE ( COMPLETE,

1")

DEFINE ( PRESENT,

1")

16.8.1.2 Document profile constraints

16.8.1.2.1

CASE

$FDA:

PERM

REQ

PERM

$PDA:

PERM

REQ

Presence of document

constituents

{($DAC) OF

Generic- layout -s true ture

Specific- layout -s true ture

Presentation- styles

Generic- layout-structure

Generic- logical-structure

{$ COMPLETE)

;

{$ PRESENT}

;

{$PRESENT}

{$ COMPLETE}

;

{$COMPLETE}

16-26
December '89

REQ

PERM

PERM

$FPDA:

REQ

REQ

REQ

REQ

PERM

PERM

)

Specific- logical -structure

Layout -styles

Presentation- styles

Generic- layout-structure

Specific- layout- structure

Generic -logical -structure

Specific- logical -structure

Layout- styles

Presentation- styles

{$ PRESENT}

{$ PRESENT)

{$ PRESENT)

{$ COMPLETE)

;

{$PRESENT)

;

{$ COMPLETE)

{$PRESENT)

{$ PRESENT)

{$ PRESENT)

PERM External -document -class

PERM Resource -document

PERM Resources

(ANY)

{ANY)

(ANY)

16. 8.1. 2.2 Document characteristics

REQ

REQ

Document-application-profile {-- ASN.l object identifier to be

supplied -

- )

;

Doc-appl -profile- defaults

{ #Document-architecture-defaults

CASE {($DAC) OF

$FDA:

#Content-architecture-class {$FC)

,

$PDA:

#Content-architecture-class {$PC)

$FPDA:

#Content-architecture-class {$FPC)

,

)

-- Common Assured Reproduction Area of --

-- North American Letter Portrait and ISO A4 Portrait

#Page -dimensions {9240, 12400),

-- Nominal Page Size NAL Portrait, "unspecified" -- #Medium-type {10200,13200,0) ),

#Character-contents -defaults

ISO 8859-1 subrepertoire -- #Graphic-char-subrepertoire {8) ) );

REQ Document-architecture-class

REQ Content-architecture-class

REQ Interchange-format-class

REQ ODA-vers ion

{ANY)

;

{ANY)

;

{if-a)

;

{"ISO 8613," "1989-02-08")

16-27
December '89

REQ Non-basic-doc-characteristics {

{ #Profile-character-sets { $CHAR- SET-LIST }

;

#Comment-character-sets { $CHAR-SET-LIST)

;

#Alternative- representation- character- sets

{$CHAR- SET- LIST)

;

#Dociiment- constituent -at tributes {

{ #Page- dimensions { $NON-BASIC-PAG-DIM)

,

#Medium-types { $NON-BASIC-NOM-PAG-SIZ) } ) };

PERM Additional-doc-characteristics {

{ #Fonts-list (ANY),

#Unit-scaling (ANY) } };

16.8.1.2.3 Document management attributes

PERM Title

PERM Subject

PERM Document- type

PERM Abstract

PERM Document -date -and- time

PERM Ke3rwords

PERM Document -reference

PERM Dates-and- times

PERM Originators

PERM Other-user- information

PERM External-references

PERM Local- file-references

PERM Content-attributes

PERM Security- information

{ANY)

(ANY)

(ANY)

(ANY)

(ANY)

(ANY)

(ANY)

(ANY)

{ANY)

{AI^Y)

(ANY)

{ANY)

{ANY)

{ANY)

16.8.2 Logical Constituent Constraints

16.8.2.1 Diagrams of Relationships of Logical Constituents

16-28
December '89

Logdoc

U

Ser

Poss

Title

Text Geometric

Iter

Any

Figure Passage

Raster Numbered

Segment

Seq

Paragraph

U

Number U

Figure 16.4. Diagram of logical structure (1 of 4)

16-29
December '89

ConiinonContent

Iter

Any

Raster Geometric Text PageNumber

Figure 16.5. Diagram of logical structure (2 of 4).

Z

Number TitleT

Y'

Iter

Any

Raster Geometric

Figure 16.6. Diagram of logical structure (3 of 4)

16-30
December '89

Text

Iter

Any

Figure

Y' Z

Geometric

Raster

Y" Phrase FNote

Ser

Number FNBody

Ser

Number Y"

Reference

Poss

PhraseF

Poss

Text Ref Text

Y"

Figure 16.7. Diagram of logical structure (4 of 4)

16-31
December

16.8.2.2 Macro definitions

DEFINE (N,

<n>

DEFINE ( NUMBERS,

<numbers>

DEFINE (NUMBERSTRINGS

,

<numberstrings>

DEFINE ( PREFIXES,

<prefixes>

DEFINE (SUFFIXES,"

<suffixes>

DEFINE (SEPARATORS ,

<separators>

--any character string from the set

of characters: "0," "1," "9"-- ")

'number- "<$N> ")

'numbers tring-"<$N> ")

'prefix- "<$N> ")

• suffix- "<$N> ")

'separator- "<$N> ")

DEFINE(INITIALISEANY,

<binding-pair-constraint> :=

{ <$PREFIXES>, STRING_LITERAL | <$SUFFIXES>, STRING_LITERAL | <$SEPARATORS>, STRING_LITERAL | <$NUMBERS>, STRING_LITERAL | <$NUMBERSTRINGS>, "

"

) + ")

DEFINE (USENUMBERS ,

<binding-pair-constraint> :=

{ <$NUMBERS>,INC(B_REF(PREC(CURR_OBJ)) (<$NUMBERS>) ) | <$NUMBERSTRINGS>, <hierarchic-expr> | <s imp le - expr>

) +

<hierarhic-expr>

<simple-expr>

<string-function>

DEFINE (SEGMENTNUMBER,

<string-expr-constraint>

B_REF ( SUP ( CURR_OBJ )

)

(<$NUMBERSTRINGS>) + B_REF ( SUP ( CURR_OBJ )

)

(<$SEPARATORS>) + <simple-expr) "

)

<string- function>

( B_REF ( CURR_OBJ ) ( $NUMBERS ) ) | <string-function> (ORD(CURR_OBJ) ) | <STRING-LITERAL>

MK_STR I U_ALPHA | L_ALPHA | U_ROM

I L_ROM ")

[<pre-stl>] <num-stl> [<suf-stl>]

16-32
December ' 89

<num-stl>

<pre-stl>

<suf-stl>

DEFINE (PAGENUMBERl ,

<string-expr-constralnt>

<pgpre-st2>

<pgsuf-st2>

<pgnum-st2>

<nuiner i c - expr - 1 >

<c lass -or- type- 1>

<c lass -or- type- 2>

DEFINE (REF, " <string-expr-constraint>

<pre-st4>

<suf-st4>

<nvini-st4>

<any-object>

B_REF ( SUP ( CURR_OBJ )

)

(<$NUMBERSTRINGS>)

B_REF ( SUP ( CURR_OBJ )

)

I STRING_LITERAL

B_REF ( SUP ( CURR_OBJ )

)

I STRING_LITERAL ")

(<$PREFIXES>)

(<$SUFFIXES>)

[<pgpre-st2>] <pgniini-st2>

[<pgsuf-st2>]

STRING_LITERAL

STRING_LITERAL

<string-function>

(<numeric-expr-l>)

B_REF ( SUP ( CURR_INST

(

<class-or-typel>, CURR_OBJ)))

($NUMBERS I "PGnura") | B_REF(CURR_INST(<class-or-type2>,

GURR_OBJ)) ($NUMBERS | "PGnum")

frame | OBJECT_CLASS_ID_OF( { FrameH

I FrameJ | FrameK})

page I OBJECT_CLA.SS_ID_OF(Page) ")

[<pre-st4>] <num-st4> [<suf-st4>]

B_REF(<any-object>) (<$PREFIXES>) | STRING_LITERAL

B_REF(<any-object>) (<$SUFFIXES>) | STRING_LITERAL

B_REF ( <any - obj e c t>

)

(<$NUMBERSTRINGS>)

OBJECT_CLASS_ID_OF( { Logdoc | Passage | NumberedSegment | Number

I Title I TitleT | Paragraph | Phrase | PhraseF | FNote | FNBody | Figure | Text | Reference | Ref | Raster | Geometric | CommonContent

I PageNumber | LayDoc | PageSet | Page I Header | Footer j BodyFramel

I BodyFrame2 j FrameA | FrameB | FrameC | FrameD | FrameE | FrameF | FrameG j FrameH | Frame I | FrameK | Block)) ")

16.8.2.3 Factor constraints

16-33
December ' 89

FACTOR: ANY-LOGICAL {

GENERIC:

REQ Object-class-identifier {ANY};

PERM Resource (ANY)

;

SPECIFIC:

REQ Object- identifier (ANY);

SPECIFIC_AND_GENERIC

:

PERM Protection {ANY}

PERM User-readable-conunent {ANY}

PERM User-visible-name {ANY}

)

FACTOR: COMP- LOGICAL : ANY-LOGICAL {

GENERIC:

REQ Object-type { composite- logical-obj ect }

;

SPECIFIC:

REQ Subordinates {ANY}

;

PERM Object-type {composite-logical-object};

SPECIFIC_AND_GENERIC

:

PERM Layout-style { STYLE_0F(LStyle3) }

;

PERM Default-value- lists {ANY};

}

FACTOR: BASIC -LOGICAL : ANY-LOGICAL {

GENERIC:

REQ Object-type {basic-logical-object};

SPECIFIC:

PERM Object-type {basic- logical-obj ect }

;

PERM Content-portions {ANY}

;

)

16.8.2.4 Logdoc : ANY- LOGICAL i

GENERIC:

REQ Object -type

REQ Generator-for-subordinates

SPECIFIC:

{ document- logical-root }

;

{ ser(poss (Title)

,

( i ter ( any ( Paragraph

,

Figure , NumberedSegment

,

Text .Raster .Geometric

,

Passage))) }

;

16-34
December ' 89

REQ Object-class

REQ Subordinates

PERM Object -type

SPECIFIC_AND_GENERIC

PERM Layout -style

PERM Bindings

PERM Default-value- lists

PERM Application-comments

)

{OBJECT_CLASS_ID_OF(Logdoc) }

;

(ANY)

;

{ document- logical-root

}

{STYLE_OF(LStylel) }

;

{$INITIALISEANY}

;

(ANY)

;

{"Logdoc")

;

16.8.2.5 Passage : COMP-LOGICAL i

GENERIC:

REQ Generator- for- subordinates

SPECIFIC:

REQ Object-class

SPECIFIC_AND_GENERIC

PERM Bindings

PERM Application-comments

)

{ ser(poss(Title)

,

iter (any (Paragraph,

Figure , NumberedSegment

,

Text , Raster , Geometric

,

Passage) ) ) )

;

{ OBJ ECT_CLASS_ID_OF( Pas sage) )

;

{$INITIALISEANY

$USENUMBERS }

;

{ "Passage" )

;

16.8.2.6 NumberedSegment COMP: -LOGICAL i

GENERIC:

REQ Generator-for-subordinates

REQ Bindings

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Bindings

PERM Application-comments

SPECIFIC_AND_GENERIC

)

{seq(Number, { ser(poss (Title)

,

i ter ( any ( Paragraph

,

Figure , NumberedSegment

,

Text , Raster , Geometric

,

Passage))))))

;

{$USENUMBERS}

{ "NumberedSegment" }

;

{ OBJ ECT_CLAS S_I D_0F

(

NumberedSegment) )

;

{$INITIALISEANY | $USENUMBERS)

;

{ "NumberedSegment" )

;

16.8.2.7 Number : BASIC-LOGICAL 1

16-35
GENERIC:

REQ Content- generator

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Presentation-style

PERM Layout- style

PERM Content-architecture-class

)

16.8.2.8 Title

GENERIC

:

REQ Generator-for-subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

)

16.8.2.9 TitleT

GENERIC:

REQ Generator-for-subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

)

16.8.2.10 Paragraph

GENERIC:

REQ Generator-for-subordinates

REQ Application-comments

SPECIFIC:

December '89

$SEGMENTNUMBER}

;

"Number" )

;

OBJECT_CLASS_ID_OF(Number) )

;

"Number" )

;

STYLE_OF(PStylel) )

;

STYLE_0F(LStyle4) } $CF I $CP I $CFP);

COMP- LOGICAL i

{ iter (any (Text , Reference,

Phrase, FNote, Figure, Raster,

Geometric) ) )

;

{ "Title" }

;

OBJECT_CLASS_ID_OF(Title) }

;

"Title" )

;

COMP -LOGICAL i

{ iter (any (Text , Reference,

Phrase, PhraseF, FNote))};

{ "TitleT" }

;

{OBJECT_CLASS_ID_OF(TitleT) }

;

{"TitleT")

;

COMP -LOGICAL i

{ iter (any (Text , Reference,

PhraseF, Phrase, FNote,

Figure, Raster, Geometric)));

{ "Paragraph" )

;

16-36
December

REQ Object-class

PERM Application-comments

)

16.8.2.11 Phrase

GENERIC

REQ Generator- for- subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

)

16.8.2. 12 PhraseF

GENERIC:

REQ Generator- for- subordinates

REQ Application- comments

SPECIFIC:

REQ Object-class

PERM Application-comments

}

16.8.2.13 FNote

GENERIC:

REQ Generator- for- subordinates

REQ Application-comments

SPECIFIC:

REQ Object- class

PERM Application-comments

SPECIFIC_AND_GENERIC

PERM Bindings

{ OBJECT_CLASS_ID_OF(

Paragraph) )

;

{ "Paragraph" )

;

:COMP- LOGICAL i

{ iter (any(Text , Reference,

Phrase, PhraseF, FNote))};

{ "Phrase" }

;

{ OBJ ECT_CLASS_ID_OF( Phrase) )

;

{ "Phrase" )

;

:COMP-LOGICAL i

{ iter (any (Text , Reference,

PhraseF) ) }

;

{ "PhraseF" )

;

{OBJECT_CLASS_ID_OF(PhraseF) )

;

{"PhraseF")

;

: COM? -LOGICAL i

{ser(Number, FNBody) )

;

{ "FNote" }

;

{OBJECT_CLASS_ID_OF(FNote) )

;

{ "FNote" }

;

{$INITIALISEANY | $USENUMBERS)

;

16-37
December '89

16.8.2. 14 FNBodv

GENERIC

:

REQ Generator -for -subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

}

16.8.2.15 Figure

GENERIC:

REQ Generator- for- subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Bindings

}

16.8.2.16 Text

GENERIC:

REQ Application-comments

SPECIFIC:

REQ Object- class

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Content-architecture -class

PERM Content-portions

PERM Presentation- style

PERM Layout- style

}

:COMP- LOGICAL i

{ser (Number, Text, Reference,

PhraseF}

;

{"FNBody"}

;

{OBJECT_CLASS_ID_OF(FNBody) )

;

{"FNBody")

:COMP-LOGICAL i

{ ser (poss (Number) , TitleT,

iter (any(Text , Reference,

PhraseF, Phrase, FNote,

Raster, Geometric))));

{ "Figure" )

;

{OBJECT_CLASS_ID_OF(Figure) )

;

{ "Figure" )

;

{$INITIALISEANY | $USENUMBERS)

;

: BASIC-LOGICAL i

{ "Text" )

;

{ OBJ ECT_CLASS_ID_OF( Text) )

;

{ "Text" )

;

{$CF I $CP I $CFP);

{ANY)

;

{STYLE_0F(PStyle2) )

;

{STYLE_0F(LStyle5) )

;

16.8.2. 17 Reference : COMP- LOGICAL i

16-38
December '89

GENERIC:

REQ Generator- for- subordinates

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

SPECIFIC_AND_GENERIC

PERM Bindings

)

16.8.2.18 Ref

GENERIC:

REQ Application-comments

SPECIFIC:

REQ Object- class

PERM Application-comments

SPECIFIC_AND_GENERIC

PERM Content -generator

PERM Content-portions

PERM Content-architecture-class

PERM Presentation-style

PERM Layout- style

)

16.8.2.19 Raster

GENERIC:

REQ Application-comments

SPECIFIC:

REQ Object-class

PERM Application-comments

SPECIFIC_AND_GENERIC

PEEIM Content-architecture-class

PERM Content-portions

PERM Presentation-style

PER^I Layout- style

)

{ ser (poss (Text) , Ref,

poss(Text) ) )

;

{ "Reference" )

;

{ OBJ ECT_CLAS S_ID_OF

(

Reference) )

;

{ "Reference" }

;

{$INITIALISEANY | $USENUMBERS)

;

: BASIC-LOGICAL i

{ "Ref" }

;

{OBJECT_CLASS_ID_OF(Ref) }

;

{"Ref")

{$REF)

;

(ANY)

;

{$CP 1 $CFP};

{STYLE_0F(PStyle2) )

;

{STYLE_0F(LStyle5) }

: BASIC-LOGICAL i

{ "Raster" )

;

{OBJECT_CLASS_ID_OF(Raster) )

;

{"Raster")

{$RFP};

{ANY)

;

{STYLE_0F(PStyle3) )

;

{STYLE_0F(LStyle6) )

16.8.2.20 Geometric : BASIC-LOGICAL 1

16-39
December '89

GENERIC:

REQ Application-comments {"Geometric");

SPECIFIC:

REQ Object-class { OBJECT_CLASS_ID_OF(

Geometric) )

;

PERM Application-comments {"Geometric");

SPECIFIC_AND_GENERIC

:

PERM Content-architecture-class {$GFP);

PERM Content-portions {ANY};

PERM Presentation-style { STYLE_0F(PStyle4) )

;

PERM Layout-style { STYLE_0F(LStyle6) )

;

)

16.8.2.21 CommonContent i

GENERIC: ; REQ Object -type

REQ Object-class-identifier

REQ Generator-for-subordinates

REQ Application- comments

PERM Resource

PERM User -readable -comments

PERM User-visible-name

PERM Protection

PERM Default-value- list '

}

{ composite- logical-obj ect }

;

{ANY)

;

{ iter (any (Raster , Geometric,

Text, PageNumber) ) )

;

{ "CommonContent" )

;

{ANY)

{ANY)

{ANY)

{ANY)

(ANY)

16.8.2.22 PageNumber

GENERIC:

REQ Object- type

REQ Object-class-identifier

REQ Content- generator

PERM Resource

PERM Presentation-style

PERM Content-architecture-class

PERM User-readable-comments

PERM User-visible-name

PERM Protection

PERM Layout- style

PERM Application-comments

}

{basic- logical-obj ect )

;

{ANY)

;

{$PAGENUMBER1 )

;

{ANY)

{STYLE_0F(PStyle2) )

;

{$CP)

{ANY)

{ANY)

{ANY)

{STYLE_0F(LStyle2) )

;

{ "PageNumber" )

;

16-40
December '89

16.8.3 Layout Constituent Constraints

16.8.3.1 Diagrams of Relationships of Layout

Constituents

Poss

Page Rep

Page

Laydoc

Iter

PageSet

Ser

Any

Poss

VPage

RPage VPage

X X

Seq

Poss

Poss

Rep

Seq

RPage

Figure 16.8. Diagram of Layout Structure (1 of 4).

16-41
December '89

Set

Any Any

Poss

Frame

K

BodyFrame2

Opt

FrameJ

Poss

Header

FrameA

BodyFramel

Any

Poss

Footer

Opt

FrameJ

Seq (in any order)

Iter

Any

FrameH FrameG BodyFramel

Seq

Block

f : Fixed position

v: Variable position

Figure 16.9. Diagram of Layout Structure (2 of 4).

16-42
December '89

Iter

Any

Frame

C

FrameH

Any

FrameH

Iter

Any

FrameG

Seq

Block

f : Fixed position

v: Variable position

Frame

B

W

FrameC

Iter

Any

FrameD FrameF

Any

Iter

FrameE

Iter

FrameG

FrameH

f : Fixed position

v: Variable position

Figure 16.10. Diagram of Layout Structure (3 of 4)

16-43
December '89

Iter

FrameA

FrameA

Frame

C

W

Any

Iter

Any

Frame

I

VAny

Iter

Any

Frame

D

Iter

Poss

Frame

E

Iter

FrameG

Frame

F

f: Fixed position

v: Variable position

Figure 16.11. Diagram of Layout Structure (4 of 4).

16.8.3.2 Macro definitions

DEFINE (PAGENUMBER- 2

,

<string-expr-constraint> :=

<numeric- express ion- 2> :=

<string-function>

(<numeric- express ion- 2>)

B_REF( SUP_OBJ( CURR_INST( frame,

CURR_OBJ ) ) )

( " PGnum" ) "

)

DEFINE(PAGE-DIMENSIONS, " -- Common Assured Reproduction Area of --

-- North American Letter and ISO A4 Portrait -- #horizontal <= 9240, #vertical <= 12400 ( -- Assured Reproduction Area of --

-- North American Letter Portrait -- #horizontal <= 9240, #vertical <= 12400 \ -- Assured Reproduction Area of ISO A4 Portrait --

16-44
#horizontal <= 9240, #vertical <= 13200 ")

DEFINE(NOMINAL-PAGE-SIZE, " -- North American Letter Portrait -- #horizontal <= 10200, #vertical <= 13200 | -- ISO A4 Portrait -- #horizontal <= 9920, #vertical <= 14030 ")

16.8.3.3 Factor constraints

FACTOR: ANY-LAYOUT {

GENERIC:

REQ Object-class

SPECIFIC:

REQ Object- identifier

SPECIFIC_AND_GENERIC

PERM User-visible-name

PEIiM User-readable-comment

)

FACTOR: ANY- PAGE : ANY- LAYOUT

GENERIC:

REQ Object -type

REQ Generator -for -subordinates

PERM Resource

SPECIFIC:

REQ Subordinates

PEEIM Object -type

SPECIFIC_AND_GENERIC

:

PERM Dimensions

PERM Transparency

PERM Colour

PERM Page-position

PERM Bindings

)

(ANY)

;

{ANY)

(ANY)

;

(ANY);

{page}

;

{ set (any (opt (FrameJ)

,

poss (Header) )

,

any (opt (FrameK)

,

poss (BodyFramel )

,

poss (BodyFrame2) )

,

any (opt (FrameJ)

,

poss (Footer) ) ) )

;

{ANY}

;

{ANY)

{page}

;

{$PAGE-DIMENSIONS

{ANY)

{AfJY)

{ANY)

{ MANI PULATI ON ( PGnum

)

FACTOR: ANY- FRAME : ANY- LAYOUT

16-45
December '89

GENERIC

:

REQ Object -type

SPECIFIC:

PERM Object -type

)

16.8.3.4 Lavdoc

GENERIC

:

REQ Object- type

REQ Generator- for- subordinates

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Object -type

SPECIFIC_AND_GENERIC

:

PERM Default-value- lists

PERM Bindings

PERM Application-comments

}

16.8.3.5 PageSet

GENERIC:

REQ Object -type

REQ Generator- for- subordinates

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Object -type

SPECIFIC_AND_GENERIC

:

PERM Bindings

PERM Application-comments

{ frame )

;

{ frame )

;

: ANY- LAYOUT i

{document-layout-root)

;

{ iter (pageset) )

;

(ANY)

;

{OBJECT_CLASS_ID_OF(Laydoc) )

;

(ANY)

{ document- layout -root )

;

(ANY)

;

{ Initialization(PGnum) )

;

{"Laydoc"}

;

: ANY-LAYOUT i

(pageset)

;

{ ser (poss (Page)

,

any (rep (Page)

,

seq(poss (RPage) , poss rep

seq(VPage, RPage),

poss(VPage)))))

;

(ANY);

{OBJECT_CLASS_ID_OF(PageSet) } ;

(ANY);

(pageset)

;

( Initialization(PGnum) )

;

( "PageSet" )

;

16-46
December '89

16.8.3.6 Page : ANY- PAGE 1

SPECIFIC:

REQ Object-class

SPECIFIC_AND_GENERIC

PERM Medium- type

#Nomlnal -page -size

#Side-of-sheet

PERM Application-comments

)

{ OBJ ECT_CLASS_ID_OF( Page)

}

{{$NOMINAL-PAGE-SIZE)

,

{"unspecified") );

{"Page")

;

16.8.3.7 RPape

SPECIFIC:

REQ Object-class

SPECIFIC_AND_GENERIC

PERM Medium- type

#Nominal -page - s ize

#Side-of-sheet

PERM Application-comments

: ANY- PAGE i

{OBJECT_CLASS_ID_OF(RPage) }

;

({$NOMINAL- PAGE- SIZE)

,

{"recto") );

{ "RPage" )

;

16.8.3.8 VPage

SPECIFIC:

REQ Object- class

SPECIFIC_AND_GENERIC

PERM Medium- type

#Nominal -page -size

#Side-of-sheet

PERM Application-comments

: ANY- PAGE i

{OBJECT_CLASS_ID_OF(VPage) )

;

{{$NOMINAL- PAGE- SIZE)

,

{"verso") );

{ "VPage" )

;

16.8.3.9 Header :ANY-FRAME 1

GENERIC

REQ Generator-for-subordinates

REQ Position

REQ Dimensions

REQ Application- comments

PERM Resource

{any(iter(any(FrameC , FrameH) )

,

iter (any (FrameH , FrameG) ) ) )

;

{#fixed{ANY) )

;

{#horizontal{#f ixed{ANY} )

,

#vertical{#f ixed{ANY} ) )

;

{ "Header")

;

(ANY)

;

16-47
December

SPECIFIC:

REQ Object- class

REQ Subordinates

PERM Imaging- order

PERM Application-comments

{OBJECT_CLASS_ID_OF(Header) }

;

{ANY}

;

{ANY}

;

{ "Header" }

;

SPECIFIC_AND_GENERIC

:

PERM Transparency {ANY}

;

PERM Colour {ANY}

PERM Border {ANY}

PERM Layout -path {90 | 270};

)

16.8.3. 10 Footer :ANY-FRAME i

GENERIC:

REQ Generator-for-subordinates

REQ Position

REQ Dimensions

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Imaging-order

PERM Application-comments

{ any(iter(any(FrameC , FrameH) )

,

iter(any(FrameH, FrameG) ) ) }

;

{#fixed{ANY) }

;

{ANY}

;

{"Footer"};

{ANY}

{OBJECT_CLASS_ID_OF(Footer) }

;

{ANY}

;

{ANY}

;

{#fixed{ANY) }

;

{ANY}

{ "Footer" }

;

SPECIFIC_AND_GENERIC

:

PERM Transparency

PERM Colour

PERM Border

PERM Layout -path

)

{ANY]

{ANYl

{ANY]

{90 I 270)

16.8.3.11 BodvFramel : ANY- FRAME 1

GENERIC:

REQ Generator-for-subordinates { iter (any (FrameB , FrameC

,

FrameD , FrameF , FrameH) ) }

;

REQ Position {#fixed{ANY) }

;

REQ Dimensions {#horizontal {#fixed{ ANY) }

,

#vertical{#fixed{ANY} } }

;

REQ Application-comments { "BodyFramel " }

;

PERM Resource (ANY)

;

16-48
Decembe

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PEEIM Imaging-order

PERM Application- comments

SPECIFIC_AND_GENERIC

PERM Transparency

PERM Colour

PERM Border

PERM Layout -path

)

{ OBJECT_CLASS_ID_OF

( Body Frame 1 ) )

;

(ANY)

(ANY)

{ANY}

(ANY)

{ "BodyFramel" )

;

(ANY)

(ANY)

(ANY)

(90 I 270)

16.8.3. 12 BodyFrame2 : ANY-FRAME

GENERIC:

REQ Generator- for- subordinates

REQ Position

REQ Dimensions

REQ Application-comments

PERM Resource

{ seq(iter(any(FrameA, FrameH,

FrameG , BodyFrame 1 ) ) ) )

;

{#fixed{ANY) )

;

{#horizontal{#fixed{ANY} )

,

#vertical{#fixed{ANY) ) )

;

{ "BodyFrame 2" )

;

{ANY}

;

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Imaging-order

PERM Application-comments

{ OBJECT_CLASS_ID_OF

(BodyFrame2) )

;

{ANY}

{ANY}

{ANY}

{ANY}

{"BodyFrame2")

;

SPECIFIC_AND_GENERIC

PERM Transparency

PERM Colour

PERM Border

PERM Layout -path

}

{ANY)

{ANY)

{ANY)

{90 I 270);

16-49
16.8.3. 13 FrameA : ANY- FRAME 1

GENERIC:

REQ Position

REQ Dimensions

REQ Application-comments

SPECIFIC:

REQ Object -class

REQ Subordinates

PERM Position

PERM. Dimensions

PEEIM Imaging- order

PERM Application- comments

SPECIFIC_AND_GENERIC

:

PERM Permitted-categories

PERM Transparency

PERM Colour

PERM Border

)

1 6.8.3.14 FrameB

GENERIC:

REQ Generator- for- subordinates

REQ Position

REQ Dimensions

REQ Application- comments

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Imaging-order

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Permitted-categories

PERM Transparency

PERM Colour

PERM Border

PERM Layout -path

{#fixed{ANY) | #variable{ANY) }

;

{#horizontal{ANY)

,

#vertical{ANY} j #horizontal { fixed, default),

#vertical(RuleB) )

;

{"FrameA")

;

{ OBJ ECT_CLASS_ID_OF( FrameA) )

;

{ OBJ ECT_ID_OF( Block) )

;

(ANY)

;

(ANY)

(ANY)

;

{"FrameA");

{ANY)

{ANY)

{ANY)

{ANY)

: ANY- FRAME i

{ any ( iter (FrameA)

,

iter(any(FrameA, Framel) ) ) )

;

(#variable{ANY) )

;

{#horizontal{ fixed {ANY)

,

default )

, #vertical { RuleB ) )

;

{"FrameB")

;

{OBJECT_CLASS_ID_OF(FrameB) )

;

{OBJECT_ID_OF(Block) )

;

{ANY}

;

{ANY)

{ANY)

;

{ "FrameB" )

;

{ANY)

;

{ANY)

{ANY)

;

{ANY)

{0| 90| 270);

16-50
December ' 89

PERM Balance (ANY]

)

16.8.3.15 FrameC

GENERIC:

REQ Position

REQ Dimensions

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Imaging-order

PERK Application-comments

SPECIFIC_AND_GENERIC

PERM Permitted-categories

PERM Transparency

PERM Colour

PEEIM Border

: ANY- FRAME 1

{#variable{ANY) }

;

(#horizontal{ fixed (ANY)

,

default), #vertical (RuieB) )

;

{"FrameC")

;

(ANY)

;

{OBJECT_CLASS_ID_OF(FrameC) )

;

{OBJECT_ID_OF(Block) )

;

(ANY)

;

{ #horizontal { default )

,

#vertical{ANY} )

;

(ANY)

;

{"FrameC")

;

{ANY)

;

(ANY)

;

(ANY)

(ANY)

16.8. 3. 16 FrameD

GENERIC:

REQ Generator- for- subordinates

REQ Position

REQ Dimensions

REQ Layout -path

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PEEIM Position

PERM Dimensions

PEIiM Imaging-order

PERM Application-comments

: ANY- FRAME i

{ any( iter (FrameE)

,

iter(FrameG) ) )

;

{#variable{ANY) )

;

{#horizontal{default}

,

#vertical (RuleA) )

;

(0 I 180);

{ "FrameD" )

;

(ANY)

;

{ OBJ ECT_CLASS_ID_OF( FrameD) )

;

{ANY}

;

(ANY)

{#horizontal{ default)

,

#vertical{ANY} )

;

(ANY)

;

{ "FrameD" )

;

16-51
December '89

SPECIFIC_AND_GENERIC

:

PERM Transparency

PERM Colour

PERM Border

PERM Bindings

)

{ANY}

(ANY)

(ANY)

{MANIPULATION(PGnum) )

;

16.8.3.17 Frame

E

GENERIC:

REQ Position

REQ D imens i ons

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Iraaging-order

PERM Application-comments

SPECIFIC_AND_GENERIC

:

REQ Permitted-categories

PERM Transparency

PERM Colour

PERM Border

)

16.8.3.18 FrameF

GENERIC:

REQ Position

REQ Dimensions

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

: ANY- FRAME i

{#variable{ANY) )

;

{#horizontal{RuleB, fixed,

default )

, #vertical { RuleB ) )

;

{"FrameE"}

;

(ANY);

(OBJECT_CLASS_ID_OF(FrameE) }

;

{OBJECT_ID_OF( Block) )

;

(ANY)

;

{ANY}

;

{ANY}

;

{"FrameE"}

;

{ANY}

{ANY}

{ANY}

{ANY}

: ANY- FRAME i

{#variable{

#fillorder{reversed} )

,

#offset{ANY}

,

#separation{ANY)

,

#alignment{ANY} )

;

{#horizontal{ default}

,

#vertical{ RuleB} }

;

{ "FrameF" }

;

{ANY);

{OBJECT_CLASS_ID_OF( FrameF) )

;

{OBJECT_ID_OF(Block) )

;

{ANY}

;

16-52
December '89

PERM Dimensions

PERM Imaging- order

PERM Application-comments

SPECIFIC_AND_GENERIC

REQ Permitted-categories

PERM Transparency

PERM Colour

PERM Border

)

16.8.3. 19 FrameG

GENERIC:

REQ Position

REQ Dimensions

REQ Application-comments

PERM Generator- for- subordinates

PERM Resource

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Imaging- order

PERM Application-comments

SPECIFIC_AND_GENERIC

PERM Permitted-categories

PERM Transparency

PEIiM Colour

PERM Border

)

16.8.3.20 FrameH

GENERIC:

REQ Position

REQ Dimensions

REQ Logical -source

REQ Application-comments

PERM Generator- for- subordinates

PERM Resource

{#horizontal { default )

,

#vertical{ANY) )

;

{ANY)

;

{"FrameF" }

;

(ANY)

(ANY)

{ANY}

{ANY}

: ANY- FRAME 1

{#fixed{ANY} }

;

{#horizontal{ANY}

,

#vertical{ANY} }

;

{ "FrameG" )

;

{ seq { Block} }

;

{ANY}

;

{ OBJ ECT_CLASS_ID_OF( FrameG) )

;

{OBJECT_ID_OF(Block) )

;

{ANY)

;

{ANY)

{ANY}

;

{ "FrameG" )

;

{ANY)

{ANY)

{ANY)

{ANY)

: ANY- FRAME 1

{#fixed{ANY} | #variable{ANY} }

;

{#horizontal { default }

,

#vertical{RuleB) )

;

{OBJECT_CLASS_ID_OF(

CommonContent) )

;

{"FrameH")

;

{ iter(Block) }

;

{ANY}

;

16-53
December '89

SPECIFIC:

REQ Object- class

REQ Subordinates

PERM Position

PERM Dimensions

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Border

PERM Layout -path

)

16.8.3.21 Framel

GENERIC:

REQ Generator-for-subordinates

REQ Position

REQ Dimensions

REQ Application-comments

PERM Resource

SPECIFIC:

REQ Object- class

REQ Subordinates

PERM Position

PEEIM Dimensions

?ERK Imaging- order

PERM Application-comments

SPECIFIC_AND_GENERIC

:

PERM Layout -path

PERM Transparency

PERM Colour

PERM Border

{OBJECT_CLASS_ID_OF(FrameH) }

;

{OBJECT_ID_OF(Block) )

;

{ANY}

;

{#horizontal{ default)

,

#vertical{ANY} )

;

{"Frame");

{ANY);

{ANY)

;

:ANY-FRAME i

{ any ( iter (any (FrameC

,

FrameD.FrameF))

,

iter(FrameG) ) )

;

{#fixed{ANY) | #variable { ANY)

;

{ #hor izontal { fixed , default }

,

#vertical{RuleB) }

;

{"Framel");

{ANY)

;

{OBJECT_CLASS_ID_OF(FrameI) )

;

{ANY);

(ANY)

;

{ANY)

;

{ANY)

{ "Framel" )

;

{90 I 270);

{ANY)

;

{ANY)

{ANY)

;

16.8.3.22 FrameJ

GENERIC:

REQ Logical -source PERM Position

PERM Dimensions

SPECIFIC:

REQ Object- class

: ANY- FRAME 1

{ANY)

;

{#fixed{ANY) )

;

{#fixed{ANY) )

{ OBJ ECT_CLASS_ID_OF( FrameJ) )

;

16-54
December '89

REQ Subordinates

PERM Position

PERM Dimensions

PERM Layout -path

SPECIFIC_AND_GENERIC

PERM Application-comments

}

{OBJECT_ID_OF( Block) )

;

(ANY)

;

{#fixed{ANY) )

;

(270)

{ "FrameJ")

;

16.8.3.23 FrameK

GENERIC:

PERM Position

SPECIFIC:

REQ Object-class

REQ Subordinates

PERM Position

PERM Layout -path

SPECIFIC_AND_GENERIC

PERM Dimensions

PERM Application- comments

)

16.8.3.24 Block

GENERIC

REQ Object- type

REQ Content-architecture-class

PERM Content-generator

REQ Application- comments

PERM Resource

SPECIFIC:

REQ Content-architecture-class

PERM object -type

PERM Position

PERM Dimensions

PERM Initial-offset

PERM Formatting- indicator

PERM Graphic -rendition

PERM Graphic-character-set

PERM Application-comments

SPECIFIC_AND_GENERIC

PERM Content-portions

PERM Transparency

PERM Colour

: ANY- FRAME i

{#fixed{ANY} }

;

{OBJECT_CLASS_ID_OF( FrameK) )

;

{OBJECT_ID_OF(Block) )

;

(ANY)

;

{270};

{#fixed{ANY) )

;

{"FrameK")

;

: ANY-LAYOUT 1

(block)

;

(ANY)

;

{$PAGENUMBER-2)

;

{"Block")

;

(ANY)

;

(ANY)

{Block)

;

{#fixed{ANY) )

;

{#horizontal{#fixed{ANY) )

,

#vertical{#fixed{ANY) ) )

;

(ANY)

;

{ANY)

;

{ANY)

(ANY)

{ "Block" )

;

(ANY)

;

(ANY)

(ANY)

16-55
December '89

PERM Border

PERM Presentation-style

)

(ANY)

;

{STYLE_ID_OF(PStylel | PStyle2

I PStyleS I PStyle4};

16.8.4 Layout style constraints

16.8.4.1 Factors

FACTOR ANY-LAYOUT -STYLE {

REQ Layout-style- identifier

PERM User-visible-name

PERM User-readable-comments

}

{ANY}

(ANY)

{ANY}

16.8.4.2 LStvlel

REQ Layout- obj ect-class

)

: ANY-LAYOUT -STYLE i

{OBJECT_CLASS_ID_OF(Laydoc) }

;

16.8.4.3 LStvle2 : ANY-LAYOUT -STYLE i

PERM Block-alignment

PERM Concatenation

PERM Indivisibility

PERM Layout -category

PERM Layout-object-class

PERM New- layout-object

PEEIM Same- layout-object

PERM Offset

PERM Separation

)

{ANY}

{ANY}

{ANY}

{ANY}

{ANY}

{ANY}

{ANY}

{ANY}

{ANY}

16.8.4.4 LStvleS : ANY -LAYOUT -STYLE i

PERM Indivisibility

PERM Layout-object-class

PERM New- layout-obj ect

PERM Same- layout-obj ect

PERM Synchronization

}

{ANY}

{ANY)

{ANY)

{ANY)

{ANY)

16-56
December '89

16.8.4.5 LStvIe4 : ANY -LAYOUT -STYLE 1

PERM Block-alignment

PERM Concatenation

PERM Indivisibility

PEEIM Layout-category

PERM Layout-object- class

PERM New- layout-object

PERM Same -layout -object

PERM Offset

PERM Separation

PERM Synchronisation

)

(ANY)

(ANY)

(ANY)

{ANY}

(ANY)

(ANY)

(ANY)

(ANY)

{ANY)

{ANY)

16.8.4.6 LStvleS : ANY- LAYOUT -STYLE 1

PERM Block- alignment

PERM Concatenation

PERM Indivisibility

PERM Layout-category

PERM Layout-object-class

PERM New- layout -object

PERM Same -layout -object

PERM Offset

PERM Separation

PERM Synchronisation

PERM Fill -order

}

(ANY)

(ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

16.8.4.7 LStvle6 : ANY-LAYOUT -STYLE i

PERM Block-alignment

PERM Indivisibility

PERM Layout -category

PERM Layout - obj ect- class

PERM New- layout -object

PERM Same -layout -object

PERM Offset

PERM Separation

PERM Synchronisation

)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

16-57
December ' 89

16.8.5 Presentation style constraints

16.8.5.1 Macros

DEFINE (C-PRES-ATTR,

PERM Alignment

PERM Character- fonts

PERM Character-orientation

PERM Character-path

PERM Character-spacing

PERM Code -extension- announcer

PERM First-line-offset

PERM Formatting- indicator

PERM Graphic-character-sets

PERM Character- subrepertoire

PERM Graphics -rendition {ANY}

PERM Indentation {ANY}

PERM Initial-offset {ANY}

PERM Itemization {ANY}

PERM Kerning-offset {ANY}

PERM Line- layout- table {ANY}

PERM Line -progress ion {ANY}

PERM Line -spacing {100 150

PERM Orphan- size {ANY}

PERM Pairwise -kerning {ANY}

PERM Proportional- line-spacing {ANY}

PERM Widow-size {ANY} ")

DEFINE (R- PRES - ATTR ,

PERM Pel-path {ANY}

PERM Line -progress ion {ANY}

PERM Pel-spacing {75 1 100

300 1 400

PERM Spacing-ratio {ANY)

PERM Clipping {ANY}

PERM Image - dimens ions {ANY) ")

ANY)

ANY)

ANY)

ANY)

ANY)

ANY)

ANY)

ANY)

$CHAR-SET-LIST)

;

2 -- Minimal --

3 -- Teletex --

5 -- ISO 646 --

8 -- ISO 8859-1 - );

I 200 I 300 I 400);

400 I 600 I 1200);

DEFINE(G-PRES-ATTR,

PERM Geometric -graphics -encoding- announcer

{ #VDC-type

#Integer -precis ion

#Real -precis ion

#Index-precision

#Colour -precis ion

#Colour- index-precision

#Maximum- CO lour- index

{ANY)

{16

{{0

{8 I {8 I

I 32)

9 23)

16} , 16),

{8 I 16),

(ANY)

,

I {1 16 16)),

16-58
December '89

PERM

PERM

PERM

{

PERM

{

#Co lour -value -extent

#Colour- selection-mode

#VDC- integer-precision

#VDC- real -precis ion

Line -rendition

Marker - r endi t ion

Text-rendition

#Font-list

#Character- set- list

#Character- coding- announcer #Text -bundle- index

#Text - font - index

#Text -precis ion

#Character-expansion- factor

#Charac ter - spac ing

#Text-colour

#Charac ter -height

#Charac ter -orientation

#Text-path

#Text- alignment

#Character- set- index

#Text-asf

#Text -bundle -representation

Filled- area- rendition

(ANY)

(ANY)

:

{16 I {{0 9 {ANY}

:

{ANY)

;

32} , 23} '

I (1 16 16) ) }

{ANY)

,

{$CHAR-SET-LIST)

,

{basic-7-bit | basic

{ANY)

.

{ANY)

,

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

{ANY)

,

{ANY)

{ANY)

{ANY)

{ANY)

{ANY) );

bit) ,

#Fill-bundle- index {ANY)

,

#Interior- style {ANY)

#Fill-colour {ANY)

#Hatch- index {ANY)

,

#Pattern- index {1 .. 8} , #Fill- reference -point {ANY)

,

#Pattern-size {ANY)

#Pattern- table -representation

{ #Pattern- table- index {1 .. 8),

#Numbe r - o

f - c o 1 umns {1 .. 16) , #Number-of -rows {1 .. 16) , #Local- CO lour -precis ion {0 1 1 1 8 #Colour-arry {ANY} } , #Fill-asf (ANY) );

PERM Edge -rendition {ANY}

,

PERM Co lour -representation (ANY)

;

PERM Transparency- specification (ANY)

;

PERM Trans format ion- specification (ANY)

;

PERM Region-of-interest-specif ication {ANY)

;

PERM Picture -orientation {ANY}

;

PERM Picture -dimensions {ANY} ")

I 16),

16-59
December '89

16.8.5.2 Factors

FACTOR: ANY- PRESENTATION- STYLE { REQ Presentation-style- identifier (ANY)

PERM User-readable-comments

PERM User-visible-name

PERM Border

PERM Colour

PERM Transparency

)

(ANY)

(ANY)

(ANY)

{ANY}

{ANY}

16.8.5.3 PStvlel : ANY- PRE S ENTATI ON - S TYLE i

PEEIM Presentation-Attributes

) {$C-PRES-ATTR}

;

16.8.5.4 PStvle2 : ANY- PRESENTATION- STYLE i

CASE ( Document -profile (Document -characteris tics

#Content-archicture-class) ) OF

$FDA:

REQ Content-architecture-class

$PDA:

REQ Content-architecture-class

$FPDA:

REQ Content-architecture-class

-- ENDCASE -- PERM Presentation-attributes

)

{$CF};

{$CP}

;

{$CFP}

;

{$C-PRES-ATTR}

;

16.8.5.5 PStyle3 : ANY- PRESENTATION- STYLE i

REQ Content-architecture-class

PERM Presentation-attributes

}

{$RFP}

;

{$R-PRES-ATTR}

;

16.8.5.6 PStvle4 : ANY- PRESENTATION- STYLE i

REQ Content-architecture -class

PERM Presentation-attributes

)

{$GFP}

;

{$G-PRES-ATTR}

;

16-60
December '89

16.8.6 Content portion constraints

16.8.6.1 Character content portion

SPECIFIC_AND_GENERIC

PERM Content- identifier- layout (ANY);

PERM Content-identifier-logical {ANY);

REQ Type -of- coding {28360};

PERM Alternative -representation {ANY)

;

PERM Content- information {

{ #Character {ANY),

-- Shared Control Functions -- #CR { ) , #GCC {ANY),

#IGS {ANY),

#LF { ) , #PLD { }

,

#PLU { ) , #SCS (ANY),

#SGR (ANY),

#SHS {0 I 1 I 2 I 3),

#SLS (ANY)

,

#SRS {ANY)

#STAB {ANY)

,

#SUB { )

,

#SVS (ANY),

#VPB (ANY),

#VPR (ANY)

,

-- Layout Control Functions --

#HPB (ANY),

#HPR (ANY)

,

#JFY (ANY),

#SACS (ANY)

,

#SRCS (ANY)

#SSW (ANY),

-- Logical Control Functions -- #BPH { )

,

#NBH ( ) , #PTX (ANY),

-- Delimiter Functions -- #SOS { )

,

#SP (},

#ST { ) )

;

16.8.6.2 Raster graphics content portion

16-61
December '89

DEFINE(T6,

DEFINE(T41D,

DEFINE (T42D,

DEFINE (BITMAP,

{2 8 3 7 0}")

{2 8 3 7 1}")

{2 8 3 7 2}")

{2 8 3 7 3}")

PERM Content- identifier- logical (ANY);

PERM Content- identifier- layout {ANY};

REQ Type -of- coding {$T6 | $T41D | $T42D | $BITMAP)

;

PERM Alternative -representation (ANY)

;

PERM Coding-attributes {

( #Compression (ANY)

,

#Number- of -lines (ANY),

#Nuiiiber-of -pels-per- line (ANY),

);

PERM Content- information {ANY};

16.8.6.3 Geometric graphics content portion

PERM Content- identifier- logical {ANY};

PERM Content- identifier- layout {ANY};

REQ Alternative-representation {ANY};

PERM Content- information {ANY};

-- Annex B.2 contains a recommended functional subset of the COM

standard for this DAP --

16.8.7 Additional usage constraints

No other usage constraints are currently defined.

16.9 INTERCHANGE FORMAT

Interchange format class "A" is to be used in this

application profile, as defined in ISO 8613-5.

The encoding is in accordance with the Basic Encoding Rules

for Abstract Syntax Notation One (ASN.l), as defined in ISO

8825.

16.9.1 ASN.l generation constraints

There are no additional constraints, beyond ISO 8824

and ISO 8825, imposed on the ASN.l generation.

16-62
December '89

16.9.2 ASN.l parsing constraints

There are no additional constraints, beyond ISO 8824

and ISO 8825, imposed on the ASN.l parsing.

16.9.3 ASN.l generation recommendations

The focus of the ASN.l generation recommendations is to

generate ASN.l encodings that will allow parsing by the

most rudimentary of implementations.

16.9.3.1 Ordering of set members

ISO 8824 defines sets to be unordered list of

values. It is the generator's option to select an order for the values of the set. Since this

ordering is unpredictable from one implementation

to the next, it is recommended that generators

order the values in a set according to the order

in which the members appear in the definition of

the set. The intent of this recommendation is to

reduce the possible interoperability problems

associated with the unpredictable ordering of

members in a set.

16.9.4 ASN.l parsing recommendations

The overall intent of these parsing recommendations is

to allow a high tolerance in the representation of the

ASN.l syntax without jeoperdizing the semantics of the

information being conveyed.

16.9.4.1 Encoding of application comments

ISO 8613-5 defines the encoding of the attribute

Application Comments as an octet string. This DAP

requires that the encoding within that octet

string be in accordance with the ASN.l syntax

specified in the following module definition.

NISTDAPSpecification

DEFINITION := BEGIN

EXPORTS Application- Comments -Encoding;

Application-Comments -Encoding := SEQUENCE { Constraint-name [0] IMPLICIT PrintableString

16-63
December '89

External-data [1] EXTERNAL)

END

16-64
December '89

16. 10 ANNEX A IMPLEMENTATION CONFORMANCE STATEMENT

16.10.1 Generator support statement proforma

The proforma for the GSS will be provided in the next

version of this document.

16.10.2 Receiver support statement proforma

The proforma for the RSS will be provided in the next

version of this document.

16. 11 ANNEX B INFORMATIVE RECOMMENDATIONS

16.11.1 Overview of technical specifications

FrameA is a region of the page typically representing a column. The direct subordinates are blocks of content.

FrameA is at a fixed or variable position within its

superior frame. The dimension orthogonal to the layout

path is fixed or variable; in the direction of the

layout path, the dimension is the minimum size needed

to contain the subordinates

.

FrameB is a region of the page, typically representing

a number of columns. The direct subordinates may only

be frames of type A or I . The position is variable

(i.e., determined by a rule). The dimension

orthogonal to the layout path is maximum for the

position; in the direction of the layout path, the

dimension is the minimum size needed to contain the

subordinates

.

FrameC is a region of the page, typically representing

an area of variable dimension within a column, such as

is needed to contain a paragraph of text or a figure.

This provides for varying layout on pages (columns or pages) as the document is edited. The direct

subordinates are blocks of content. The position is

variable (i.e., determined by a rule). The dimension

orthogonal to the layout path is maximum for the

position; in the direction of the layout path, the

dimension is the minimum size needed to contain the

subordinate block(s)

.

16-65
December '89

FrameD is a region of the page, typically representing

an area of variable dimension within a column,

containing a number of items side by side (e.g., text

flowing around a picture) . The direct subordinates may

only be frames of type E. The position is variable

(i.e., determined by a rule). The dimension

orthogonal to the layout path is maximum for the

position; in the direction of the layout path, the

dimension is the minimum size needed to contain the

first laid out subordinate (e.g., the picture).

FrameE is a region of the page, typically representing

some text or a picture, that is side by side with the

frames of this type within a superior frame of type D.

The direct subordinates are blocks of content. The

position is variable (i.e., determined by a rule).

The dimension orthogonal to the layout path is the

minimum size needed to contain the subordinate

block(s) . In the direction of the layout path, the

dimension is either a fixed dimension or is a computed

dimension equal to either the minimum size needed to

contain the subordinate block(s) (e.g., picture), or

the maximum size for the position (e.g., text).

Frame F is a region of the page typically used to

contain a footnote. The direct subordinates are blocks

of content. The frame is positioned within its

superior in reverse order at a fixed position from its

superior in the direction orthogonal to the layout path

and at a variable position in the direction of the

layout path. The dimension orthogonal to the layout

path is maximum for the position; in the direction of

the layout path, the dimension is the minimum size

needed to contain the subordinate blocks

.

FrameG is a region of the page, typically representing

a set of pieces of content placed at defined positions.

This provides for complex, fixed, relatively positioned

pieces of content, including overlapping pieces of

content (e.g., overlapping pictures or pictures and

text). The direct subordinates are blocks of content.

The position relative to the superior is fixed; the

dimensions are also fixed.

FrameH is a region of the page, typically representing

a variable piece of logical information in the header

or footer area of a page (e.g., current chapter

number) . The direct subordinates are blocks of

content. The frame, in all cases, specifies that its

content is derived from the use of the attribute

16-66
December '89

"logical source" referring Co a logical object of

"header or footer content." The position is fixed or variable (i.e., determined by a rule.) The dimension

orthogonal to the layout path is maximum for the

position; in the direction of the layout path, the

dimension is the minimum size needed to contain the

subordinate blocks.

Frame I: A region of the page typically representing a column. The frame may contain any substructure of

further frames of any of the types C, F, or G . Blocks

are not permitted directly subordinate to Framel.

Framel is at a fixed or variable position within its

superior frame. The dimension orthogonal to the layout

path is fixed; in the direction of the layout path, the

dimension is the minimum size needed to contain the

subordinates

.

Frame J is a single basic frame to contain header or footer contents. This is provided for compatibility

with the CCITT Recommendation T.502.

Frame K is a single basic frame to represent the body

area of a page. This is provided for compatibility with

the CCITT Recommendation T.502.

16. 11 .2 ISO 8632 (CGM) constraints for this DAP

It is recommended that geometric graphics content

information contain only those elements listed in this

portion of the Annex, in addition to the constraints

imposed by ISO 8613-8. It is believed that this subset

of the CGM is sufficiently widely implemented to enable

interworking of geometric graphics for application

conforming this DAP.

The content information of a content portion

description that conforms to this content architecture

is an ASN.l octet string representing a Computer

Graphics Metafile (CGM) conforming to the following

constraints

a) Conform to part 1 of the ISO 8632 standard;

b) Conform to the binary encoding defined in

part 3 of the ISO 8632 standard;

c) Consist of a single picture;

d) Conform to the ISO pdISP FCG13, except as noted with respect to font and colour table

support;

16-67
December '89

e) Generalized Drawing Primitives are ignored;

f) ESCAPE Elements are ignored;

g) External Elements may be ignored.

The following list is a description of the constraints

for each of the CGM elements. Where an element has

parameters, recommended constraints on the values are

given. The symbol indicates that there is no recommended constraint.

Requirements in ISO 8632 and ISO 8613-8 concerning

mandatory elements, parameters must be fulfilled.

16.11.2.1 Delimiter elements

No-Op

Begin Metafile

End Metafile

Begin Picture

Begin Picture Body

End Picture

See Note 1 See Note 2

See Note 2

16.11.2.2 Metafile description elements

Metafile Version

Metafile Description

VDC Type

Integer Precision

Real Precision

Index Precision

Colour Precision

Colour Index Precision

Maximum Colour Index

Colour Value Extent

Metafile Element List

Metafile Defaults Replacement

Font List

Character Set List

Character Coding Announcer

See Note 5 basic-7-bit, basic-8-bit

1See Notes 2, 3

8, 16

(0,9.23), (1,16,16)

16

8, 16

8, 16

See Note 4

16.11.2.3 Picture descriptor elements

Scaling Mode

Colour Selection Mode

See Note 6

Line Width Specification Mode

Marker Size Specification Mode

Edge Width Specification Mode

16-68
VDC Extent

Background Colour

16.11.2.4 Control elements

VDC Integer Precision 16, 32

VDC Real Precision (0.9,23), (1,16,16)

Auxiliary Colour

Transparency

Clip Rectangle

Clip Indicator

16.11.2.5 Graphical primitive elements

Polyline See Note 7 Disjoint Polyline See Note 7 Polymarker See Note 7 Text See Note 2 Restricted Text See Notes 2, 8

Append Text See Notes 2, 8

Polygon See Note 7 Polygon Set See Note 7 Cell Array See Note 9

Rectangle

Circle

Circular Arc 3 Point

Circular Arc 3 Point Close

Circular Arc Centre

Circular Arc Centre Close

Ellipse

Elliptical Arc

Elliptical Arc Close

16.11.2.6 Attribute elements

Line Bundle Index

Line Type

Line Width

Line Colour

Marker Bundle Index

Marker Type

Marker Size

Marker Colour

Text Bundle Index

Text Font Index

Text Precision

Character Expansion Factor

Character Spacing

Text Colour

16-69
December '89

Character Height

Character Orientation

Text Path

Text Alignment

Character Set Index

Alternate Character Set Index

Fill Bundle Index

Interior Style

Fill Colour

Hatch Index

Pattern Index 1 . . 8

Edge Bundle Index

Edge Type

Edge Width

Edge Colour

Edge Visibility

Fill Reference Point

Pattern Table See Notes 10, 11

Pattern Size

Colour Table Specification See Notes 12, 13

Aspect Source Flags

16.11.2.7 External Elements

Message

Application Data

No action

See Note 2

Note 1: An arbitrary sequence of n octets.

Where n=0, 1, .., 32767. The

sequence of zero or more octets is

for padding purposes

.

Note 2: Support will be provided for

strings with a length up to 256

octets, except for data records

which will support strings with a length up to 32767 octets.

Note 3: The METAFILE DESCRIPTION string

parameter will be used to include

the sub- string "ISO FCG13" to label

the content information as conforming to this agreement. In

addition, generator of content are encouraged to append a sub -string

that identifies the company and

product that produced the CGM.

16-70
December '89

Note 4: The METAFILE DEFAULTS REPLACEMENT

element shall not be partitioned.

No part of the element will be

partitioned. Multiple occurances

of the MDR element may be used to

avoid the need for partitioning.

The MDR element must appear in the

CGM to establish the defaults for

TEXT PRECISION and any other

elements whose defaults are different than those specified in

ISO 8632-1 and -3.

Note 5: Only those character set that are permitted in character content can

be specified in geometric graphics

content. Refer to 7.1, Document

profile, for constraints on character sets in character

content

.

Note 6: The Scale Factor parameter of

SCALING MODE element is always a 32-bit floating point value, even when the REAL PRECISION has

selected fixed point for other real

numbers. It is not apparent in ISO

8632 what the precision of this

floating point value is when fixed

point has been selected. Its

precision shall be (0,9,23).

Note 7: The minimum support for the length

of point lists is 1024 elements.

Note 8: The complete restricted text

string, including appended text,

shall be included in a metafile

conforming to this agreement. The

complete restricted text string

shall be scaled isotropically such

that the specified aspect ratio for

the text is not distorted and the

string fits into the text extent

parallelogram

.

Note 9: The minimum support for the length

of colour lists parameter for the

CELL ARRAY element is 1,048,576.

This supports a 1024x1024 image.

16-71
December '89

Note 10: The PATTERN TABLE element has an unspecified effect when it appears

in a picture subsequent to any

graphical primitives. The PATTERN

TABLE element shall appear prior to

any graphical primitive element to assure that interpreting systems

without dynamic pattern update can render the intended effect.

Note 11: The minimum support for the length

of the Colour Array parameter for

the PATTERN TABLE element is 2048.

This will support 8 patterns of

16x16.

Note 12: The COLOUR TABLE element has an unspecified effect when it appears

in a picture subsequent to any

graphical primitives . The COLOUR

TABLE element shall appear prior to

any graphical primitive elements to assure that interpreting systems

without dynamic colour update can render the intended effect.

Note 13: The minimum support for the length

of the Colour List parameter in the

COLOUR TABLE element is 61. This

will support a 63 entry colour

table

.

16.11.3 Interoperability with SGML Applications

The recommended method for the exchange of documents

between Standard Generalized Markup Language (ISO 8879,

SGML) based systems and systems based on this ODA

document application profile is by means of exchanging

a document representation conforming to these

agreements in an encoded form of the SGML language

known as the Office Document Language (ODL) . ODL is a standardized SGML application for representing

documents conforming to the ODA base standard. Such a representation can be converted into the Office

Document Interchange Format (ODIF) supported by these

agreements

.

16-72
December '89

17. FUTURE OFFICE DOCUMENT ARCHITECTURE (PDA)

Editor's Note: This section will contain the new

text relating to Office Document

Architecture (ODA) Agreements.

17-1

June 1990 (Stable))

1 8 NETWORK MANAGEMENT

18.1 INTRODUCTION

Within the community of OSI researchers, users, and vendors, there is a recognized need to address the

problems of initiating, terminating, monitoring, and controlling communication activities and assisting in their harmonious operation, as v^^ell as handling abnormal conditions. The activities that address these problems

are collectively called network management.

Network management can be viewed as the set of operational and administrative mechanisms necessary

to:

a. bring up, enroll, and/or alter network resources,

b. keep network resources operational,

0. fine tune these resources and/or plan for their expansion,

d. manage the accounting of their usage, and

e. manage their protection from unauthorized use/tampering.

As such, network management is typically concerned with management activities in at least the following

five functional areas: configuration management, fault management, performance management, accounting

management, and security management. In order to accomplish these management activities, information

must be exchanged among open systems.

In Part 18, there are Implementation Agreements (lA's) for providing interoperable OSI management

information communication services among OSI systems. Also contained here are agreements on management information. These agreements pertain to the exchange of management information and

management commands between open systems operating in a multivendor environment. For example, one

goal is to ensure that a management system built by one vendor can manage objects built by another

vendor.

18.1.1 References

The following documents are referenced in the statements of the agreements relating to OIW OSI network

management.

OSI Systems Management References:

[ADDRMVP] ISO/IEC 9596/DAD 2, Common Management Information Protocol Specification:

Addendum 2 (Add/Remove Protocol), ISO/IEC JTC1/SC21, 1 February 1990.

18-1
June 1990 (Stable))

[ADDRMVS] ISO/IEC 9595/DAD 2, Common Management Information Service Definition: Addendum 2 (Add/Remove Service), ISO/IEC JTC1/SC21, 1 February 1990.

[CANGETP] ISO/IEC 9596/DAD 1 , Common Management Information Protocol Specification:

Addendum 1 (CancelGet Protocol), ISO/IEC JTC1/SC21, 1 February 1990.

[CANGETS] ISO/IEC 9595/DAD 1, Common Management Information Service Definition: Addendum 1 (CancelGet Service), ISO/IEC JTC1/SC21, 1 February 1990.

[CMIP] ISO/IEC 9596-2, Information Processing Systems - Open Systems Interconnection

- Management Information Protocol Specification - Part 2: Common Management

Information Protocol, 6 December 1989.

[CMIS] ISO/IEC 9595-2, Information Processing Systems - Open Systems

Interconnection - Management Information Service Definition - Part 2: Common

Management Information Service, 6 December 1 989.

[MIM] ISO/IEC DIS 10165-1, Information Processing Systems - Open Systems

Interconnection - Management Information Services - Structure of Management

Information - Part 1 : Management Information Model, ISO/IEC JTC1/SC21 N5252,

June 1990.

Other OSI References:

[ASN1] ISO 8824, Information Processing Systems - Open System Interconnection

Specification of Abstract Syntax Notation One (ASN.1), 19 May 1987.

18.2 SCOPE AND FIELD OF APPLICATION

(Refer to the Working Implementation Agreements Document.)

18.3 STATUS

(Refer to the Working Implementation Agreements Document.)

18.4 ERRATA

Editor's Note: "Defect Report* material (including applicability) may be included here.

(Refer to the Working Implementation Agreements Document.)

18-2
18.5 MANAGEMENT FUNCTIONS AND SERVICES

(Refer to the Working Implementation Agreements Document.)

June 1990 (Stable))

18.6 MANAGEMENT COMMUNICATIONS

18.6.1 Association Policies

(Refer to the Working Implementation Agreemerrts Document.)

18.6.2 General Agreements on Users of CMIS

The following agreements pertain to the first phase of network management implementors agreements (I As)

.

These agreements are based on the standard defined in [CMIS], [CMIP], [ADDRMVP] and [ADDRMVS]

constrain the users of CMIS services and not the implementation of CMIP itself.

18.6.2.1 Object Naming

Object Naming will be accomplished using Distinguished Name or Local Distinguished Name. Use of nonspecific form is outside the scope of these agreements.

18.6.2.2 Multiple Object Selection

Multiple Object Selection applies to all management operations except M-EVENT-REPORT, M-CREATE and

M-CANCEL-GET.

18.6.2.2.1 Scoping

These network management lAs specify that scoping will be used as specified in [CMIS] 6.5.1, 8.3.1.1.5,

8.3.2.1.6, 8.3.3.1.6, 8.3.5.1.5.

18.6.2.2.2 Filtering

These network management lAs specify that filtering will be used as specified in [CMIS] 6.5.2, 8.3.1.1.6,

8.3.2.1.7, 8.3.3.1.7, 8.3.5.1.6.

If a system receives a filter parameter that it is unable to process, it must return the error "complexity

limitation", including the CMISFilter requested.

If, in the process of filtering from a set of selected entities, there are no managed objects selected, the

system must return an empty response consisting of an Invoke ID and no response argument.

18-3
June 1990 (Stable))

18.6.2.2.3 Synchronization

In order to support interoperability between managing systems and managed systems, these network

management lAs define that the default synchronization (i.e., BestEffort) must be supported by all conforming systems. Atomic synchronization may also be supported as an option.

If a performer is unable to comply with a synchronization request specified by an invoker, the performer must

return the error "synchronization not supported" with the parameter indicating the synchronization not supported.

18.6.2.2.4 Muitipie Replies

These network management lAs specify the use of multiple replies as specified in [CMIS] 7.1, 7.2.3.

18.6.2.3 Current/Event Time

The time value that is reported to CMIS, if provided, should be as close as possible to, but not before, the

actual time that the operation to which the reported time value applies occurred. This constraint is stipulated

to provide the most accurate timestamp for temporal ordering of operations and events on a single open

system.

For these network management I As, the encoding of the Current Time parameters is ASN.1 Generalised

Time, UTC Type, as specified in [ASN1 ] clause 32.3, b) and c), with the precision of the time representation

indicating the granularity of the time measurement. For example, the string 19890613123012.333-0500

represents a local time of 12:30:12 (and 333 msecs) on 13th June 1989, in a time zone which is 5 hours

behind GMT.

1 8.6.2.4 Access Control

Conformant implementations are not required to use this field. The Access Control field, if provided by the

invoker in CMIS request indicators, may be ignored by responding systems which do not support access

control. These systems must not reject a request on the basis of the presence of access information. The

invoker may interpret this as acceptance of the access control parameter.

18.6.2.5 CI\/!iS Functional Units

Only the Kernel Functional Unit must be supported. Other functional units except Extended Service are

optional and their use must be negotiated as specified in [CMIS]. Extended Service is not within the scope

of these agreements. Negotiation for its "non use" must be supported.

18.6.2.6 CI\/IIS Parameters

The CMIS globalForm must be used for the following parameters:

18-4
June 1990 (Stable))

action type id attribute id event type id object class

Use of localForm is outside the scope of tfiese agreements.

18.6.3 Specific Agreements on Users of CMIS

These agreements pertain to the first phase of network management implementors agreements (I As). These

agreements are based on the standard defined in [CMIS] and [ADDRMVS]. The agreements in this clause

have been defined in terms of those capabilities necessary to support the functions and services defined

in clause 18.5 (Management Functions and Services) of these agreements. These agreements constrain

the users of CMIS services and not the implementation of CMIP itself.

The parameter presence information in the tables in this clause are repeated from [CMIS] and have the same

meaning as in the standard. They are repeated for reader convenience. In addition, these tables provide

references to text clauses where agreements are stated relative to parameters in each table. The lack of a

reference signifies no agreement beyond the base standard.

18.6.3.1 M-Event-Report

The following agreements and clarifications, pertinenttosection8.2ofthe base standard [CMIS] and section

6.3 of the base standard [CMIP] and regarding the M-EVENT-REPORT service, are included within these

network management lAs.

Clause 1 8.5 (Management Functions and Services) of these agreements defines some of the types of Event

Reports that may be sent.

18.6.3.1.1 Event Argument

All arguments defined for the particular event type of the managed object class (see sec. 18.7, Management

Information Agreements) for the M-EVENT-REPORT must be supplied in the Event Argument parameter.

The Event Information and Event Reply parameters shall be supplied as specified for the event type.

18.6.3.1.2 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are refined by the referenced agreement.

18-5
June 1990 (Stable))

Table 1 : M-EVENT REPORT Parameters

Item

Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 18.6.4

2 Mode M _

3 Managed Object Class M U 18.6.2.6

4 Managed Object Instance M U 18.6.2.1

5 Event Type M c= 18.6.2.6

6 Event Time U 18.6.2.3

7 Event Information U 18.6.3.1.1

8 Current Time u 18.6.2.3

9 Event Reply c

10 Errors c 18.6.4.4

18.6.3.2 M-Get

The following agreements and clarifications, pertinent to section 8.3.1 of the base standard [CMIS] and

section 6.4 of the base standard [CMIP] and regarding the M-GET service, are included within these network

management lAs.

18.6.3.2.1 Successful Response

For a successful M-GET operation, the performer shall return (in the Attribute List parameter) either the

attribute values for all attributes explicitly requested (in the Attribute Identifier List parameter), or the attribute

values for all attributes defined for the managed object(s) selected (if the Attribute Identifier List is omitted).

18.6.3.2.2 Partially Successful or Unsuccessful Response

For a partially successful M-GET operation, where only some attribute values were retrieved, the performer

shall return (in the Errors parameter, specifically encoded as GetListError) all attribute ids and their corresponding values that were successfully retrieved from the set of attributes selected as described above,

together with all attribute ids, and the corresponding error codes, for each of the attributes for which errors were detected. All attributes requested by the invoker must be processed, with either a value or an error code returned for each.

18-6
June 1990 (Stable))

18.6.3.2.3 Multiple Replies

For the final reply of a series of multiple relies or the single reply where no objects were selected when

filtering has been specified, the GetResult is omitted. Hence Managed Object Class, Managed Object

Instance, Current Time and Attribute List are all omitted in these cases.

18.6.3.2.4 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are refined by the referenced agreement.

Table 2: M-GET Parameters

Item Parameter Name Req/ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 18.6.4 o LinKeu loeniiTier C 18.6.4

3 Base Object Class M 18.6.2.6

4 Base Object Instance M 18.6.2.1

5 Scope U 18.6.2.2.1

6 Filter U 18.6.2.2.2

7 Access control U 18.6.2.4

8 Synchronization U 18.6.2.2.3

9 Attribute Identifier List U 18.6.2.6

10 Managed Object Class C 18.6.2.6

11 Managed Object Instance c 18.6.2.1

12 Current Time u 18.6.2.3

13 Attribute list c 18.6.2.6, 18.6.3.2.1, 18.6.3.2.3

14 Errors c 18.6.3.2.2, 18.6.4.4

18.6.3.3 M-Set

The following agreements and clarifications, pertinent to section 8.3.2 of the base standard [CMIS] and

section 6.5 of the base standard [CMIP] and regarding the M-SET service, are included within these network

management lAs.

18-7
June 1990 (Stable))

18.6.3.3.1 Successful Response

For a successful M-SET confirmed operation, the performer shall return (in the Attribute List parameter) the

attribute values for all attributes explicitly specified (in the Attribute List parameter) indicating their new

values.

18.6.3.3.2 Partially Successful or Unsuccessful Response

For a partially successful M-SET operation, where only some attribute values were modified, the performer

shall return (in the Errors parameter, specifically encoded as SetListError) all attribute ids and their corresponding values that were successfully modified from the set of attributes ids and values supplied, and

all attribute ids and the corresponding error codes for each of the attributes for which errors were detected.

All attributes requested by the invoker must be processed, with either a value or an error code returned for each.

18.6.3.3.3 Multiple Replies

For the final reply of a series of multiple relies or the single reply where no objects were selected when

filtering has been specified, the SetResult is omitted. Hence Managed Object Class, Managed Object

Instance, Current Time and Attribute List are all omitted in these cases.

1 8.6.3.3.4 Add/Remove Response

Where multi-valued attributes are involved in an M-SET operation [ADDRMVS] , the values returned after any

modification operation must be the full set of values of that attribute and not just the values that were

modified (e.g., added or removed).

1 8.6.3.3.5 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions specified in [CMIS] unless those

conditions are modified by the referenced agreements.

18-8
Table 3: M-SET Parameters

June 1990 (Stable))

item Parameter Name Req/Ind Rsp/Conf Text Reference

1 11 IVUKc; lUUllUllol M KAf—\ M(-) in1 o.o.»t R A

o LiiiKec] iu6niiii6r 1 O.D.»* oo IVIOU6 M

AH M

c M 1 ft R O 1

RKJ U 1 Q C O O 1

7 Filter u - 18.6.2.2.2

8 Access control u - 18.6.2.4

9 Synchronization u 18.6.2.2.3

10 Managed Object Class C 18.6.2.6

11 Managed Object Instance - c 18.6.2.1

12 Modification List M 18.6.2.6, 18.6.3.3.1,

18.6.3.3.3, 18.6.3.3.4

13 Attribute List u 18.6.2.6, 18.6.3.3.1,

18.6.3.3.3

14 Current Time u 18.6.2.3

15 Errors c 18.6.3.3.2, 18.6.4.4

18.6.3.4 M-Action

The following agreements and clarifications, pertinent to section 8.3.3 of the base standard [CMIS] and

section 6.6 of the base standard [CMIP] and regarding the M-ACTION service, are included within these

network management lAs.

18.6.3.4.1 Multiple Objects

When multiple objects are selected for an M-ACTION operation, there is no ordering implied between

selected objects. If the ordering is important, the requesting system may use separate operations, for individual object instances, in the desired order.

18-9
June 1990 (Stable))

18.6.3.4.2 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreements.

Table 4: M-ACTION Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 18.6.4

2 Linked Identifier C 18.6.4

3 Mode M

4 Base Object Class M 18.6.2.6

5 Base Object Instance M 18.6.2.1

6 Scope u 18.6.2.2.1

7 Filter u 18.6.2.2.2

8 Managed Object Class C 18.6.2.6

9 Managed Object Instance c 18.6.2.1

10 Access control U 18.6.2.4

11 Synchronization U 18.6.2.2.3

12 Action Type M C(=) 18.6.2.6

13 Action Information U

14 Current Time u 18.6.2.3

15 Action Reply c

16 Errors c 18.6.4.4

18.6.3.5 M-Create

The following agreements and clarifications, pertinent to section 8.3.4 of the base standard [CMIS] and

section 6.7 of the base standard [CMIP] and regarding the M-CREATE service, are included within these

network management lAs,

18.6.3.5.1 Managed Object Instance

The Managed Object Instance request parameter may be present or absent depending on whether the

invoker supplies the instance name orthe performer assigns the instance name automatically. The definition

18-10
June 1990 (Stable))

of each Managed Object Class shall define whether the Instance name may be supplied by the invoker, or must be assigned by the performer. This definition shall apply to every management-initiated creation of instances of that managed object class.

18.6.3.5.2 Attribute Values

The values of each of the attributes of the newly created object are derived as defined in [MIM] 5.2.2.1 . If none of these methods provides a value for any one attribute, then the operation shall be considered to have

failed, i.e., no new instance is created, and the error code 'Missing Attribute Value' shall be returned.

18.6.3.5.3 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreement.

Table 5: M-CREATE Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 18.6.4

2 Managed Object Class M C 18.6.2.6

3 Managed Object

Instance

U c 18.6.2.1, 18.6.3.5.1

4 Superior Object Instance U 18.6.2.1

5 Access Control U 18.6.2.4

6 Reference Object

Instance

U 18.6.2.1

7 Attribute List U c 18.6.2.6, 18.6.3.5.2

8 Current Time u 18.6.2.3

9 Errors c 18.6.3.5.2. 18.6.4.4

18.6.3.6 M-Delete

The following agreements and clarifications, pertinent to section 8.3.5 of the base standard [CMIS] and

section 6.8 of the base standard [CMIP] and regarding the M-DELETE service, are included within these

Phase 1 network management lAs.

18-11
June 1990 (Stable))

18.6.3.6.1 Deletion of Objects Containing Objects

The error 'Processing Failure' must be returned if a managed object has existing contained objects and the

behavior defined for that object prohibits its deletion unless all contained objects have been deleted.

18.6.3.6.2 Parameter Agreements

Conditional parameters (C) shall be included according to the conditions defined in [CMIS] unless those

conditions are modified by the referenced agreements.

Table 6: M-DELETE Parameters

Item Parameter Name Req/Ind Rsp/Conf Text Reference

1 Invoke Identifier M M(=) 18.6.4

2 Linked Identifier C 18.6.4

3 Base Object Class M 18.6.2.6

4 Base Object Instance M 18.6.2.1

5 Scope U 18.6.2.2.1

6 Filter U 18.6.2.2.2

7 Access control U 18.6.2.4

8 Synchronization U 18.6.2.2.3

9 Managed Object Class C 18.6.2.6

10 Managed Object Instance c 18.6.2.1

11 Current Time u 18.6.2.3

12 Errors c 18.6.3.6.1, 18.6.4.4

18.6.4 Specific Agreements on CMIP

These agreements pertain to the first phase of network management implementors agreements (lAs). These

agreements are based on the standard defined in [CMIP] and [ADDRMVP]. The agreements in this clause

have been defined in terms of those capabilities necessary to support the functions and services defined

in clause 18.5 (Management Functions and Services) of these agreements.

These netv\/ork management lAs make no agreements beyond the specifications in [CMIP] and [ADDRMVP],

except the following:

18-12
June 1990 (Stable))

18.6.4.1 Invoke/Linked Identifier Size

Invoke Identifiers and Linked Identifiers must be encoded in an integer of four (4) octets maximum length.

18.6.4.2 Version

Protocol Version 2 (only) is supported.

1 8.6.4.3 Linked Reply Values

Responders must send a linked reply value that corresponds to the original invoke operation value.

1 8.6.4.4 Error Codes

Responders must send error types that correspond to the operation definition for the original invoke.

18.6.5 Services Required by CiVIIP

(Refer to the Working Implementation Agreements Document.)

18.7 MANAGEMENT INFORMATION

(Refer to the Working Implementation Agreements Document.)

18-13
{I
December '89

19. REMOTE DATABASE ACCESS (RDA)

Editor's Note: This section serves as a placeholder

for text provided by the newly- formed

Remote Database Access (RDA) Special

Interest Group,

19-1

Table of Contents

Manufacturing Message Specification (MMS) . . .

.

1 Introduction

2 Scope and Field of Appfication

3 References

4 D^nitions

7 General Agreements 1

8 Service-Specific Agreements 1 A Backwards CompatitHTrty Agreements 2

B DIS 9506 Modifications Required For Backwards Compatibinty 2

B.1 Introductkxi 2

Bj2 References 2

B.3 General 2

B.3.1 Implementation Base 2

B.3.2 Rules of ExtensibiTity 2

B.4 Modifications to ttie Protocol definitkxis 2

B.4.1 Page 39. Section 7.5JZ of DIS 9506-2 2

B.4.2 Page 49. Sectkxi 7.6.4. DIS 9506-2 3

B.4.3 Page 95, Sectkxi 12.2.1 of DIS 9506-2 3

B,4.4 Page 96, Sectkxi 1Z3.1 of DIS 9506-2 3

B.4.5 Page 98, Sectkxi 1Z4.2 of DIS 9506-2 4

B.4.6 Page 138. Sectkxi 15.14 of DIS 9506-2 4

B.4.7 Page 166, Sectkxi 17.10 of DIS 9506-2 4

8.5 Behavkxal Requirements 4

i
20MMS September 1990 (Stable)

B.5.1

B.&2

B.5.3

B.5.ai

B.5.3^ 5

B.5.4 5

B.5.5 Application Context Name 6

B.5.6 Minor Version Number 6

8.6 Parameter CBB Subset 6

8.7

- ii -
20 MMS September 1990 (Stable)

Ust of Tables

Table MMS Service Subset 7

- Ill
mci
20 MMS September 1990 (Stable)

Manufacturing Message Specification (MMS)

1 Introduction

(Refer to Working Agreements, Dated September, 1990.)

2 Scope and Field of Application

(Refer to Working Agreements, Dated September, 1990.)

3 References

(Refer to Working Agreements, Dated September, 1990.)

4 Definitions

(Refer to Working Agreements, Dated September, 1990.)

5 Errata

(Refer to Working Agreements, Dated September, 1 990.)

6 Status

(Refer to Working Agreements, Dated September, 1990.)

7 General Agreements

(Refer to Working Agreements, Dated September, 1 990.)

8 Service-Specific Agreements

(Refer to Working Agreements. Dated Septemt)er. 1990.)

-1 -
20 MMS

A Backwards Compatibility Agreements

(Refer to Working Agreements, Dated September, 1990.)

September 1990 (Stable)

B DIS 9506 Modifications Required For Backwards Compatibility

B.1 Introduction

This annex is an integral part of this part It documents the modifications to DIS 9506 required to describe

implementations for which the agreements of this part provide backwards compatibility. This annex as

applied to DIS 9506 is referred to as Version 0.

B2. References

[1] MMS/1 Manufacturing Message Specification - ISO DIS 9506 - Sen/ice Definition, December 1987

[2] MMS/2 Manufacturing Message Specification -ISO DIS 9506 - Protocol Specification, December 1 987

[3] NBS OSI Implementors Workshop Agreements - December 1987

B.3 General

B.3.1 Imptementatkxi Base

Version 0 is based upon Reference [3] in 8.2 as it applies to MMS.

B.3.2 Rules of Extensibifity

The following sentence is appended to the last paragraph in section 8.2.1 .1 .5.2 Proposed Parameter CBB

and the last paragraph in section 8.2.1.2.5.2 Negotiated Parameter CBB of DIS 9506-1.

•Any additional bits shall be ignored."

B.4 Modifications to the Protocol definitions

B.4.1 Page 39. Section 7.5.2 of DIS 9506-2

CHANGE
20 MMS September 1 990 (Stable)

reportEventEnrollmentStatus {60] IMPUCn" ReporlEventEnrollmentStatus-Request.

TO

reportEventEnrollmentStatus [60] ReportEventEnrolimentStatus-Request.

Page 49, Section 7.&4, DIS 9506-2

CHANGE

ApplicationReference ::= SEQUENCE {

ap-tltle ISO-8650-ACSE-1.AP-title OPTIONAL,

ap-invocation-id ISO-86 SO-ACSE-LAP-invocation-id OPTIONAL,

ae-qualifier ISO-8650-ACSE-1 .AE-quaiifier OPTIONAL,

ae-invocatlon-id ISO-8650-ACSE-1.AE-invocatlon-id OPTIONAL

}

TO

ApplicationReference ::= SEQUENCE {

ap-title [0] OBJECT IDENTIFIER OPTIONAL,

ap-invocation-id [1] INTEGER OPTIONAL,

ae-qualifier [2] INTEGER OPTIONAL,

ae-invocation-id [3] IfTTEGER OPTIONAL

}

B.4.3 Page 95. Section 1ZZ1 of DIS 9506-2

CHANGE

structure [2] IMPUCIT SEQUENCE OF SEQUENCE {

TO

stmcture [2] IMPUCIT SEQUENCE {

B.4.4 Page 96, Section 12.3.1 of DIS 9506-2

CHANGE

named [4] IMPUCIT SEQUENCE {

TO

named [5] IMPUCIT SEQUENCE {

-3-
20 MMS September 1990 (Stable)

B.4.5 Page 98. Section 12.42. of DIS 9506-2

CHANGE

generalized-time (10] IMPLICIT GeneralizeiJTime,

TO

generalized-time [11] IMPLICIT GeneralizecTTime,

6.4.6 Page 138. Section 15.14 Of DIS 9506-2

CHANGE

additionalDetail [9] IMPUCIT EE-Additional-Detail OPTIONAL

TO

additionalDetail [9] EE-Additional-Detail OPTIONAL

B.4.7 Page 166, Section 17.10 of DIS 9506-2

CHANGE the transfer syntax object identifier value from

{ iso asnl(1) basic-encodingO) }

TO

{

joint-iso-ccitt asn1(1) basic-encoding (1 ) }

B.5 Behavioral Requirements

B.5.1 Filenames

File Names are specified in accordance with the NBS Implementors'agreements for FTAM Reference [3] in B.2.

B.5.2 lden% Service

In the Identify service, the vendor, model and revision fields may be of any length, but only the first 64, 1 6, and 1 6 octets respectively are treated as significant.
20 MMS September 1990 (Stable)

B.5.3 initiate Service

An MMS Client will:

1. propose 1 or greater for the value of the Proposed Max Sen/ Outstanding Called parameter

in the Initiate service when initiating the application association (calling).

2. offer 1 or greater for the value of the Negotiated Max Sen/ Outstanding Calling parameter in the Initiate service when receiving the application association initiation (called).

An MMS Server will:

1. propose 1 or greater for the value of the Proposed Max Serv Outstanding Calling parameter

in the Initiate service when initiating the application association (calling).

2. offer 1 or greater for the value of the Negotiated Max Serv Outstanding Called parameter in the Initiate service when receiving the application association initiation (called).

B.5.3.1 Minimum Segment Size

MMS implementations are able to parse and process 512 octets of MMSpdu as they are encoded in ASN.1

basic encoding mles.

B.5.3.2 Maximum Segment Size

The Max Segment Size is defined as the maximum number of octets in an MMSpdu encoded using the

negotiated transfer syntax. This size will apply to all MMSpdu's with the exception of the initiate-Request

PDU, initiate-Response PDU, and the initiate-Error PDU. The max segment size will be negotiated during

connection initiation using the Proposed Max Segment Size and Negotiated Max Segment Size parameters

of the MMS initiate sen/ice.

The Max Segment Size will be applied as follows:

Any received MMSpdu which is less than or equal to the Max Segment Size will be property

parsed and processed.

An MMS implementation will not send an MMSpdu whose size exceeds the Max Segment Size.

B.5.4 Abstract Syntax Name

The ASN. 1 object identifier value for the abstract syntax name will t>€ the same as specified on page 1 66,

section 17.10 of DIS 9506-2.
20 MMS September 1990 (Stable)

B.5.5 Application Context Name

The ASN. 1 object identifler value for the application context namewilt be the same as specified on page 1 66,

section 17.1 1 of DIS 9506-2.

An MMS implementation ignores the Application Context Name in the A-Assodate indication and the AAssociate confirm.

B.5.6 Minor Version Numtser

The Minor Version Numfc>er is zero.

B.6 Parameter CBB Subset

The following subset of MMS Parameter CBBs were considered during preparation of this appendix.

STRl,

NEST,

VADR,

VNAM

B.7 Service Subset

The following subset of MMS services were considered during preparation of this appendix.
20 MMS September 1990 (Stable)

Initiate

Conclude

Cancel

Status

GetNameList

Identify

Unsol icitedStatus

GetCapabilityList

InitiateDownloadSequence

DownloadSegment

TerminateDovmloadSequence

InitiateUploadSequence

Up1oadSegment

TerminateUploadSequence

RequestDomainDownload

RequestDomainUpload

LoadDomainContent

StoreDomainContent

DeleteDomain

GetDoma inAttributes

Read

Write

InfonnationReport

GetVariableAccessAttributes

Input

Table MMS Service Subset

Output

TakeControl

RelinquishControl

ReportSemaphoreStatus

ReportPoolSemaphoreStatus

ReportSemaphoreEntryStatus

CreateProgramlnvocation

DeleteProgramlnvocation

Start

Stop

Resume

Reset

Kill

GetProgramlnvocationAttributes

ObtainFile

GetEventConditionAttributes

ReportEventConditionStatus

GetAlannSummary

ReadJournal

WriteJournal

Initial izeJournal

CreateJournal

DeleteJournal

ReportJournalStatus

-7-

U.S. GOVERNMENT PRINTING OFFICE: 1990 - 281 - 5 5 7 2 0 7 3 6

December '89

21^ REFERENCES

Selected references are grouped by organization publishing the documents

and by Reference Model layer to aid relating standards to the OSI Basic

Reference Model and to aid relating equivalent standards published by

different standards organizations.

21 . 1 CCITT

General

Application Layer - MHS

CCITT Reconunendation X.121 (1988), International Numbering Plan.

CCITT Recommendation 1.231, (Blue Book, 1988), Circuit-Mode Bearer

Service Categories.

CCITT Recommendation 1.232, (Blue Book, 1988), Packet-Mode Bearer

Services Categories.

Physical Layer

CCITT Recommendation 1.431, (Blue Book, 1988), Primary Rate UserNetwork Interface-Layer 1 Specification.

Data Link Layer

CCITT Recommendation Q. 921 (1.441), (Blue Book, 1988), ISDN UserNetwork Interfaces: Data Link Layer Specification.

Network Layer

CCITT Recommendation Q. 931 (1.451), (Blue Book, 1988), ISDN UserNetwork Interface Layer 3 Specification for Basic Call Control.

CCITT Recommendation X.25, (Yellow Book, 1980), Interface Between Data

Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE)

for Terminals Operating in the Packet Mode on Public Data Networks.

CCITT Recommendation X.25, (Blue Book, 1988), Interface Between Data

Terminal Equipment (DTE) and Data Circuit-Terminating Equipment (DCE)

for Terminals Operating in the Packet Mode and Connected to Public

Data Networks by Dedicated Circuit.

CCITT Recommendation X.31, (Blue Book, 1988), Support of Packet Mode

Terminal Equipment by an ISDN.

21-1
December '89

CCITT REcommendation X.213, (Blue Book, 1988), Network Service

Definition for Open Systems Interconnection for CCITT Applications.

Transport Layer

CCITT Recommendation X.214, (Blue Book, 1988), Transport Service

Definition for Open Systems Interconnection for CCITT Applications.

CCITT Recommendation X.224, (Blue Book, 1988), Transport Protocol

Specification for Open Systems Interconnection for CCITT Applications.

Session Layer

CCITT Recommendation X.215, (Red Book, 1984), Session Service

Definition for Open Systems Interconnection for CCITT Applications.

CCITT Recommendation X.225, (Red Book, 1984), Session Protocol Profile

for Open Systems Interconnection for CCITT Applications.

Presentation

CCITT Recommendation T.50, (Red Book, 1984), International Alphabet

No. 5.

CCITT Recommendation T.61, (Red Book, 1984), Graphic Character SetsBasic Teletex Profiles.

Application Layer -- MHS

CCITT Recommendation X.400, (Red Book, 1984), Message Handling

Systems: System Model -Service Elements.

CCITT Recommendation X.401, (Red Book, 1984), Message Handling

Systems: Basic Service Elements and Optional User Facilities.

CCITT Recommendation X.408, (Red Book, 1984), Message Handling

Systems: Encoded Information Type Conversion Rules.

CCITT Recommendation X.409, (Red Book, 1984), Message Handling

Systems: Presentation Transfer Syntax and Notation.

CCITT Recommendation X.410, (Red Book, 1984), Message Handling

Systems: Remote Operations and Reliable Transfer Server.

CCITT Recommendation X.411, (Red Book, 1984), Message Handling

Systems: Message Transfer Layer.

CCITT Recommendation X.420, (Red Book, 1984), Message

Handling Systems: Interpersonal Messaging User Agent Layer.

21-2
December '89

CCITT Recommendation X.430, (Red Book, 1984), Message Handling

Systems: Access Protocol for Teletex Terminals.

CCITT Recommendation X.400 (1988), Message Handling, System and

Service Overview.

CCITT Recommendation X.402 (1988), Message Handling Systems, Overall

Architecture

.

CCITT Recommendation X.407 (1988), Message Handling Systems, Abstract

Service Definition Conventions.

CCITT Recommendation X.411 (1988), Message Handling Systems, Message

Transfer System: Abstract Service Definition and Procedures.

CCITT Recommendation X.413 (1988), Message Handling Systems, Message

Store: Abstract Service Definition.

CCITT Recommendation X.419 (1988), Message Handling Systems, Protocol

Specifications

.

CCITT Recommendation X.420 (1988), Message Handling Systems,

Interpersonal Messaging System.

Application Layer - ODA

CCITT Recommendations

T.6 - Facsimile Coding Schemes and Coding Control Functions for Group

4 Facsimile Apparatus 1984

T.4 - Standardization of Group 3 Facsimile Apparatus for Document

Transmission 1984

T.411 - Open Document Architecture (ODA) and Interchange Format - Introduction and General Principles 1988

T.412 - Open Document Architecture (ODA) and Interchange Format - Document Structures 1988

T.414 - Open Document Architecture (ODA) and Interchange Format - Document Profile 1988

T.415 - Open Document Architecture (ODA) and Interchange Format - Document Interchange Format (ODIF) 1988

T.416 - Open Document Architecture (ODA) and Interchange Format - Character Content Architectures 1988

21-3
December '89

T.417 - Open Document Architecture (ODA) and Interchange Format - Raster Graphics Content Architectures 1988

T.418 - Open Document Architecture (ODA) and Interchange Format - Geometric Graphics Content Architectures 1988

T.501 - Document Application Profile MM for the Interchange of

Formatted Mixed Mode Documents 1988

T.502 - Document Application Profile PMl for the Interchange of

Processable Form Documents 1988

T.503 - Document Application Profile for the Interchange of Group 4

Facsimile Documents 1988

CCITT documents may be obtained from:

International Telecommunlcatloiis Union

Place des Nations, CH 1211,

Geneva 20 SWITZERLAND

21 .2 ISO

Status of ISO work can be determined by the reference number; working

drafts are referenced by committee and number; e.g., TC 97/SC 6 Nxxxx.

Standards are cited by either ISO xxxx or IS xxxx; DIS and DPs are cited in similar form. Note: ISO TC 97 is now called ISO/IEC JTCl

.

Information Processing Systems - Open Systems Interconnection - Basic

Reference Model. ISO/IS 7498. First Edition - Oct. 15, 1984. Ref.

No. ISO 7498-1984(E)

.

OSI Basic Reference Model - Part 2: Security Architecture. ISO/IS

7498-2-1988(E)

.

OSI Basic Reference Model - Part 3: Naming and Addressing. ISO/IS

7498-3-1988(E)

.

Data Interchange - Structure for the identification of organizations.

ISO 6523. 1984-02-01.

Physical Layer

Information Processing Systems - Local Area Networks - Part 3:

Carrier Sense Multiple Access with Collision Detection (CSMA/CD) and

Physical Layer Specification ISO/DIS 8802/3

Information Processing Systems - Local Area Networks - Part 4:

Token-Passing Bus Access Method and Physical Layer Specification,

ISO/DIS 8802/4

21-4
March 1990 (Stable)

ISO 8802-5 Final Text of ISO/DIS 8802-5: Info proc systems - Local

Area Nets -Part 5: Token ring access method and physical layer

specification, ISO/TC 97/SC 6 N4477,1987

Information Processing Systems - Fiber Distributed Data Interface

(FDDI) - Part 1: Token Ring Physical Layer Protocol (PHY)

Requirements; ISO 9314-1 (for Working Agreements Only).

Information Processing Systems - Fiber Distributed Data Interface

(FDDI) - Part 2: Token Ring Media Access Control (MAC) Requirements;

ISO 9314-2 (for Working Agreements Only).

Information Processing Systems - Fiber Distributed Data Interface

(FDDI) - Part 3: Physical Layer Medium Dependent (PMD) Requirements;

ISO DIS 9314-3 (for Working Agreements Only).

Data Link Layer

ISO 8802-2 Text for ISO/DIS 8802-2.2, Logical Link Control, ISO/TC

97/SC 6 N4609, 1987

Information Processing Systems - Data Communication - High-Level Data

Link Control Procedures - Description of the X.25 LAPB- compatible DTE

Data Link Procedures, ISO 7776.

Network Layer

Information Processing Systems - Data Communications - Network Service

Definition, ISO 8348.

Information Processing Systems - Data Communications - Network Service

Definition: Addendum 1: Connectionless mode Data Transmission, ISO

8348/Add. 1.

Information Processing Systems - Data Communications - Network Service

Definition: Addendum 2: Network Layer Addressing, ISO 8348/Add. 2.

Information Processing Systems - Data Communications - Internal

Organization of the Network Layer, ISO 8648.

Information Processing Systems - Data Communications - Protocol for

Providing the Connectionless-mode Network Service, ISO 8473.

Information Processing Systems - Telecommunications and Information

Exchange Between Systems - End System to Intermediate System Routing

Exchange Protocol for Use in Conjunction with the Protocol for

Providing the Connectionless-Mode Network Service (ISO 8473) , ISO

9542.

21-5
March 1990 (Stable)

Information Technology - Data Communications - X.25 Packet Layer

Protocol for Data Terminal Equipment, ISO 8208 (2nd Edition).

Information Processing Systems - Data Communications - Use of X.25 to

provide the OSI Connection-mode Network Service, ISO 8878

Information Processing Systems - Data Communications - Use of the X.25

Packet Layer Protocol in local area networks, ISO 8881.

Information Technology - Telecommunications and Information Exchange

Between Systems - Provision of the OSI Connection-Mode Network Service

by Packet Mode Terminal Equipment Connected to an Integrated Services

Digital Network (ISDN), ISO/IEC 9574.

Information Technology - Telecommunications and Information Exchange

Between Systems - Protocol Identification in the Network Layer,

ISO/IEC DTR 9577.

Information Processing Systems - Data Communications - Operation of an X.25 Interworking Unit, ISO TR 10029.

Transport Layer

Information Processing Systems - Open Systems Interconnection - Transport Service Definition, ISO 8072.

Information Processing Systems - Open Systems Interconnection - Connection-oriented Transport Protocol Specification, ISO 8073, (2nd

Edition)

.

Information Processing Systems - Open Systems Interconnection - Transport Service Definition - Addendum 1: Connectionless -Mode

Transmission, ISO 8072/Addendum 1.

Information Processing Systems - Open Systems Interconnection - Connection Oriented Transport Protocol Specification -Addendiam 1: Network Connection Management Subprotocol, ISO 8073/Addendum 1.

Information Processing Systems - Open Systems Interconnection - Connection Oriented Transport Protocol Specification -Addendum 2:

Class Four Operation Over Connectionless Network Service, ISO

8073/Addendum 2.

Information Processing Systems - Open Systems Interconnection - Protocol for Providing the Connectionless -Mode Transport Service, ISO

8602.

Session Layer

21-6
June 1990 Stable

Information Processing Systems - Open Systems Interconnection - Basic

Connection Oriented Session Service Definition, ISO 8326: 1987 (E)

.

Information Processing Systems - Open Systems Interconnection - Basic

Connection Oriented Session Protocol Specification, ISO 8327 : 1987

(E).

Information Processing Systems - Open Systems Interconnection - Basic

Connection Oriented Session Service Definition-AD 2 to ISO 8326 to

Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2494.

Information Processing Systems - Open Systems Interconnection - Basic

Connection Oriented Session Protocol Specification - AD 2 to ISO 8327

to Incorporate Unlimited User Data, ISO/IEC JTC1/SC21 N2495.

Information Processing Systems - Open Systems Interconnection-Session

Service Definition: Addendum 3 Covering Connectionless-Mode Session

Service, IS0/AD3 8326.

Information Processing Systems - Open Systems InterconnectionConnectionless Session Protocol to Provide the Connectionless-Mode

Session Service, ISO/IS 95A8.

Presentation Layer

Information Processing Systems - Open Systems Interconnection - Connection-Oriented Presentation Service Definition, ISO 8822: 1988

(ISO/IEC JTC1/SC21 N2335).

Information Processing Systems - Open Systems Interconnection - Connection Oriented Presentation Protocol Specification, ISO 8823:

1988 (ISO/IEC JTC1/SC21 N2336)

.

Interim Revised Text of ISO 8825/PDADl, ASN.l Extensions (ISO/IEC

JTC1/SC21 N2342)

.

Interim Revised Text of ISO 8824/PDADl, ASN.l Extensions (ISO/IEC

JTC1/SC21 N2341)

.

Information Processing Systems - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.l), ISO 8824: 1987

(E).

Information Processing Systems - Open Systems Interconnection - Specification of Basic Encoding Rules for Abstract Syntax Notation

(ASN.l), ISO 8825: 1987 (E)

.

Information Interchange - Representation of Local Time Differentials

,

ISO 3307.

21-7
June 1990 Stabl

Information Processing Systems - Open Systems Interconnection - Presentation Service Definition: Draft Addendum 1 Covering

Connectionless-Mode Presentation Service, ISO/DADl 8822: 1989-02-

15(e) (ISO/IEC JTC1/SC21 N 3171).

Information Processing Systems - Open Systems Interconnection - Connectionless Presentation Protocol to Provide the ConnectionlessMode Presentation Service, ISO/IS 9576: 1989-02-25 5(E) (ISO/IEC

JTC1/SC21 N 3172).

Application Layer

Information Processing Systems - Open Systems Interconnection - Application Layer Structure, ISO/DP 9545, ISO/TC97/SC21/N1743 . July

24, 1987. Revised November 1987.

ISO 10021-1 Information Processing Systems - Text Communication - MOTIS - System' and Service Overview.

ISO 10021-2 Information Processing Systems - Text Communication - MOTIS - Overall Architecture.

ISO 10021-3 Information Processing Systems - Text Communication - MOTIS - Abstract Service Definition Conventions.

ISO 10021-4 Information Processing Systems - Text Communication - MOTIS - Message Transfer System: Abstract Service Definition and

Procedures

.

ISO 10021-5 Information Processing Systems - Text Communication - MOTIS - Message Store: Abstract Service Definition.

ISO 10021-6 Information Processing Systems - Text Communication - MOTIS - Protocol Specifications.

ISO 10021-7 Information Processing Systems - Text Communication - MOTIS - Interpersonal Messaging System.

Application Layer -- FTAM

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part I: General Introduction, ISO

8571-1: 1988(E).

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part 2: Virtual Filestore Definition

ISO 8571-2: 1988(E)

.

21-8
June 1990 Stable

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part 3: The File Service Definition,

ISO 8571-3: 1988(E).

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part 4: File Protocol Specification,

ISO 8571-4: 19878(E).

Information Processing Systems - Open Systems Interconnection - File

Transfer, Access and Management Part 5: Protocol Information

Conformance Statement Proforma, ISO 8571-5: 1990(E).

Application Layer -- ASE/ACSE

Information Processing Systems - Open Systems Interconnection - Service Definition for the Association Control Service Element, ISO

8649: 1987 (E) (ISO/IEC JTC1/SC21 N2326)

Information Processing Systems - Open Systems Interconnection - Protocol Specification for the Association Control Service Element,

ISO 8650: 1987 (E) (ISO/IEC JTC1/SC21 N2327)

Information Processing System - Open Systems Interconnection - ACSE

Service Definition: Draft Addendum 2 Covering Connectionless -Mode

ACSE Service, ISO 8649/DAD2.

Information Processing Systems - Open Systems Interconnection - Connectionless ACSE Protocol to Provide the Connectionless -Mode ACSE

Service, ISO IS 10035: 1989-02-25 (ISO/IEC JTC1/SC21 N 3456).

Application Layer VTP

Information Processing Systems - Open Systems Interconnection - Virtual Terminal Service - Basic Class, IS 9040.

Information Processing Systems - Open Systems Interconnection - Virtual Terminal Protocol - Basic Class, IS 9041.

Application Process -- Office Document Interchange -- ODA

ISO 8613/1 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 1: Introduction and General Principles

ISO 8613/2 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 2: Document

Structures

ISO 8613/4 - Information processing : Text and Office Systems; Office

21-9
June 1990 Stable

Document Architecture (ODA) and Interchange Format Part 4: Document

Profile

ISO 8613/5 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 5: Office

Document Interchange Format

ISO 8613/6 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 6: Character

Content Architectures

ISO 8613/7 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 7: Raster

Graphics Content Architectures

ISO 8613/8 - Information processing : Text and Office Systems; Office

Document Architecture (ODA) and Interchange Format Part 8: Geometric

Graphics Content Architectures

Application Process -- Computer Graphics -- CGM/GKS

Information Processing Systems - Computer Graphics - Metafile (CGM)

for the Storage and Transfer of Picture Description Information, Part

1; Functional Specification, IS 8632/1

Information Processing Systems - Computer Graphics - Metafile (CGM)

for the Storage and Transfer of Picture Description Information, Part

2; Character Encoding, IS 8632/2

Information Processing Systems - Computer Graphics - Metafile (CGM)

for the Storage and Transfer of Picture Description Information, Part

3; Binary Encoding, IS 8632/3.

Information Processing Systems - Computer Graphics - Metafile (CGM)

for the Storage and Transfer of Picture Description Information, Part

4; Clear Text Encoding, IS 8632/4,

Information Processing Systems - Font and Character Information

Interchange, IS 9541.

Information Processing Systems - 8-Bit Single Byte Coded Graphic

Character Sets, Part 1; Latin Alphabet Part 1, IS 8859/1.

Information Processing Systems - Computer Graphics Functional

Specification of the Graphical Kernel System (GKS) , IS 7942.

Information Processing Systems - Computer Graphics - Graphical Kernel

System for Three Dimensions (GKS-3D), Functional Description, DIS

8805.

21-10
March 1990 (Stable)

Information Processing Systems - Computer Graphics - Programmers

Hierarchical Interactive Graphics System (PHIGS) , DP 9592.

Information Processing Systems - Computer Graphics - Interfacing

Techniques for Dialogues with Graphical Devices (CGI), ISO TC 97/SC 21

N 1179.

Application Layer -- Directory Services

The Directory- -Overview of Concepts, Models, and Services (CCITT

Recommendation X.500, ISO 9594)

The Directory- -Information Framework (CCITT Recommendation X.501, ISO

9594)

The Directory- -Access and System Services Definition (CCITT

Recommendation X.511, ISO 9594)

The Directory- -Procedures For Distributed Operation (CCITT

Recommendation X.518, ISO 9594)

The Directory- -Access and System Protocols Specification (CCITT

Recommendation X.519, ISO 9594)

The Directory- -Selected Attribute Types (CCITT Recommendation X.520,

ISO 9594)

The Directory--Selected Object Classes (CCITT Recommendation X.521,

ISO 9594)

The Directory- -Authentication Framework (CCITT Recommendation X.509,

ISO 9594)

Remote Operations-Part 1: Model, Notation and Service Definition

(CCITT Recommendation X.219, ISO 9072 Version 5)

Remote Operations -Part 'I: Protocol Specification (CCITT Recommendation

X.229, ISO 9072 Version 5)

Association Control -Service Definition (CCITT Recommendation X217, ISO

8649)

Association Control-Protocol Definition (CCITT Recommendation X.217,

ISO 8650)

Note: ISO 9594, 9072 are preferred texts (over the CCITT

counterparts) and are to be taken as of Gloucester,

Nov. 1987.

21-11
March 1990 (Stable)

Additional ISO References

ISO 8859-1 - Information Processing - 8-bit Single-byte Coded Graphic

Character Sets - Part 1: Latin Alphabet No. 1

ISO 8859-2 - Information Processing - 8-bit Single-byte Coded Graphic

Character Sets - Part 2: Latin Alphabet No. 2

DIS 8859-3 - Information Processing - 8-bit Single-Byte Coded Graphic

Character Sets - Part 3: Latin Alphabet No. 3

ISO 6937-1 - Information Processing - Coded Character Sets for Text

Communication - Part 1 : General Introduction

ISO 6937-2 - Information Processing - Coded Character Sets for Text

Communication - Part 2: Latin Alphabetic and Non-Alphabetic Graphic

Characters

ISO 2022 - Information Processing - ISO 7-Bit and 8-Bit Coded

Character Sets - Code Extension Techniques

7-Bit Coded Character Set for Information Processing Interchange, ISO

646.

ISO 6429: 1988 Information Processing - ISO 7-Bit and 8-Bit Coded

Character Sets - Additional Control Functions for Character- Imaging

Devices

.

ISO/IEC ISP AFTnn- Information Technology Processing -Systems - International Standardized Profiles AFTnn - File Transfer, Access and

Management

.

Part 1 Specification of ACSE, Presentation and Session

Protocols for the use by FTAM PDISP t989-06-01

.

1990-01-10.

Part 2 Definition of Document Types, Constraint Sets and

Syntaxes PDISP 1989-06-017 1990-01-10.

Part 2 Definition of Document Types, Constraint Sets and

Syntaxes, Addendum 1: Additional Defintions Working

Draft 1989-08-157 1990-01-10.

Part 3 AFTll-Simple File Transfer Service (Unstructured) PDISP

1989-06-017 1990-01-10.

Part 4 AFTl 2 -Positional File Transfer Service (Flat) Working

Draft 1989-08-157 1990-01-10.

21-12
March 1990 (Stable)

Part 5 AFT22-Positlonal File Access Service (Flat) Working

Draft t989-G8-l:ST 1990-01-10.

Part 6 AFT3-File Management Service Working Draft t9&9-G8-t5T

1990-01-10.

ISO documents may be obtained from:

Frances E. Schrotter

ANSI

ISO TC 97/SC 6 Secretariat

1430 Broadway

New York. NY. 10018

21 .

3

Additional References

INTAP-S007-03 - Multi-media (ODA/ODIF) Functional Standard Detail

Description (AE.llln-J), Small Function Set Profiles of Document

Interchange Format with Layout Information

INTAP-S007-04 - Multi-media (ODA/ODIF) Functional Standard Detail

Description (AE.112n-J), Medium Function Set Profiles of Document

Interchange Format with Layout Information

21.4 IEEE

Physical Layer

IEEE Standard for Local Area Networks: Carrier Sense Multiple Access

with Collision Detection (CSMA/CD) and Physical Layer Specification,

ANSI/IEEE Standard 802.3 1985, Institute of Electrical and Electronics

Engineers, 345 East 47th St., New York, NY. 10017, 1985.

IEEE Standard for Local Area Networks: Supplements to Carrier Sense

Multiple Access with Collision Detection (CSMA/CD) Access Method and

Physical Layer Specification ANSI. IEEE Standard 802.3a, b, c, e -1988

Supplement a, MAU and Baseband Medium Specification, lyp^ 10BASE2

(Section 10)

Supplement a. Broadband MAU 6e Medium Specification, Type 10BROAD36

(Section 11)

Supplement c. Repeater Set and Repeater Unit Specification for Use

with 10BASE5 and 10 BASE2 Networks

Supplement e, Physical Signaling, Medium Attachment, and Baseband

Medium Specification, Type 10BASE5

21-13
March 1990 (Stable)

IEEE Standard for Local Area Networks: Token-Passing Bus Access

Method and Physical Layer Specification, ANSI/IEEE Standard , 802.4

Draft 1987, Institute of Electrical and Electronics Engineers, 345

East 47th St., New York, NY. 10017, 1985.

IEEE Standard for Local Area Networks: Token-Ring Access Method,

ANSI/IEEE Standard 802.5- 1986, Institute of Electrical and

Electronics Engineers, 345 East 47th St., New York, NY. 10017, 1985.

Data Link Layer

IEEE Standard for Local Area Networks: Logical Link Control,

ANSI/IEEE Standard 802.2 - 1987, Institute of Electrical and

Electronics Engineers, 345 East 47th St., New York, NY. 10017, 1985.

21 .5 NBS

Implementation Agreements for Open Systems Interconnection Protocols:

NBS Workshop for Implementors of Open Systems Interconnection,

National Bureau of Standards, NBSIR 86-3385-6, Robert Rosenthal,

Editor, Revised July 1987.

U. S. Government Open Systems Interconnection Profile (GOSIP)

,

National Bureau of Standards, Institute for Computer Sciences and

Technology, 1987.

NBS documents may be obtained from:

NTIS

U.S. Department of Commerce

5285 Port Royal Road

Springfield, VA. 22161.

21 .6 MAP

Manufacturing Automation Protocol, General Motors

Corporation, Manufacturing Engineering and Development, Advanced

Product and Manufacturing Engineering Staff (APMES) , APMES A/MD-39, GM

Technical Center, Warren, MI. 48090-9040.

21.7 TOP

Technical and Office Protocols Specification Version 3.0, MAP/TOP

Users Group, Attention TOP 3.0 Document. One SME Drive, P.O. Box 930,

Dearborn Mi. 48121.

21-14
March 1990 (Stable)

21 .8 CEN/CENELEC

ENV-4]:2G4h--i988fE) ENV 41204 (revised): 1990(E) FTAM Simple File

Transfer (Unstructured), June Jan. 1990 (-proposed -revision -June -t989) .

prENV 41205 FTAM File Management, March Nov. 1989.

prENV 41206 FTAM Positional File Transfer (Flat), June-t989 Jan. 1990.

prENV 41207 FTAM Postional File Access (Flat), June-1:989 Jan. 1990.

ENV 41201 "Private Message Handling Systems"

ENV 41202 "Public Message Handling Systems"

21.9 SPAG

Guide to the Use of Standards, Revision 4.0 1989.

21 . 10 ANSI

Physical Layer

Fiber Distributed Data Interface (FDDI) - Token Ring Media Access

Control (MAC); ANS X3. 139-1987 (for Working Agreements only).

Fiber Distributed Data Interface (FDDI) - Token Ring Physical Layer

Protocol (PHY); ANS X3. 148-1988 (for Working Agreements only).

Fiber Distributed Data Interface (FDDI) - Physical Layer Medium

Dependent (PMD) ; ANS X3. 166-1989 (for Working Agreements only).

Carrier- to-Customer Installation - DSl Metallic Interface, ANS Tl.403

- 1989.

Integrated Services Digital Network - Basic Access Interface for Use on Metallic Loops for Application on the Network Side of the NT-Layer

1 Specification, ANS T1.601 - 1988.

Integrated Services Digital Network - Basic Access Interface at S and

T Reference Points - Layer 1 Specification, ANS T1.605 - 1988.

Data Link Layer

Telecommunications - Integrated Services Digital Network (ISDN) - Data-Link Layer Signaling Specification for Application at the UserNetwork Interface, ANS T1.602 - 1989.

21-15

•Cr U.S. GOVERNMENT PRINTING OFFICE: 1990 — 2 6 1 - 9 1 3 2 0 6

March 1990 (Stable)

CHANGE PAGE INDEX

VERSION 3 EDITION 1, MARCH 1990 (STABLE) CHANGE PAGES

ISSUED JTJNE 1990

OUTPUT FROM MARCH 1990 OSI WORKSHOP

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS FOR

OPEN SYSTEMS INTERCONNECTION PROTOCOLS,

VERSION 3, EDITION 1, DECEMBER 1989

NIST SPECIAL PUBLICATION 500-177

This document records, in replacement page format, all changes to stable

material current (according to Version and Edition number) as of the

previous Workshop (December 15, 1989). In this case, that would be NIST

SP 500-177, Version 3, Edition 1. By following the instructions below,

and replacing or inserting the indicated pages, a new "Edition" will be

created which reflects new the current status of relevant stable material

as of March 16, 1990.

If there are sidebars in the Table of Contents, then that document should

contain the replacement pages for March 1990. THIS INSERT SET SHOULD BE

SAVED.

The following table gives all necessary information. Entries in the

first column indicate that those pages are to be replaced with the pages

referenced in the second column.

The instructions below are given by Chapter and Page number, referring to

NIST SP 500-177. Page numbers with extra digits are "overflow" pages to

be inserted immediately after the previously-mentioned page. The

changes made are indicated by vertical bars on the left margins of

replacement pages, and all the replacement pages are dated in the upper

right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial,

other) . The term "other" may include addition of new stable

functionality. All changes apply to the previous version and edition.

Replacements reflect the following types of changes:

1, deletion of material (blank lines)

2, insertion of new material (may lead to "overflow" pages), and

3, replacement of old text with new text (combination of (1) and (2)

above

.

Technical errata are changes from implementor experience which materially

affect the meaning or semantics of a section, and editorial changes do

not change semantics. Alignment changes are material changes made in the

interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and

alignment errata are more "severe" than technical errata. If a

1
March 1990 (Stable)

particular replacement has a combination of errata, the most "severe"

errata will be checked in the replacement page table. Readers should

keep in mind that these errata may be further categorized in future

editions

.

2
March 1990 (Stable)

DELETE PAGE NUMBER INSERT PAGE NUMBER TECHNICAL ALIGNMENT EDITORIAL OTHER

iii-xxvii iii-xxvii X

1-1, 1-2 1-1, 1-2 X

2-1 - 2-2 2-1, 2-2 X

Chapter 5 Chapter 5 X

6-3 thru 6-6 6-3 thru 6-6 X

, 8-5, 8-6 8-5, 8-6 X

/ 8-29, 8-30 8-29, 8-30 X

/ 8-33, 8-34 8-33, 8-34 X

V 8-45, 8-46 8-45, 8-46 X

- 9-3, 9-4 9-3, 9-3-1 X

insert 9-4 X

/ 9-7 thru 9-12

V 9-7 thru 9-12 X

^. 9-31, 9-32 9-31, 9-31-1 X

/ insert 9-32

9-41, 9-42 9-41, 9-42 X

V insert 9-42-1 X

/ 9-43, 9-44 9-43, 9-44 X

v 9-47 thru 9-50 9-47 thru 9-50 X

/ 9-53 thru 9-56 V 9-53 thru 9-56 X

/ 9-59 thru 9-62 9-59 thru 9-62 X

v insert 9-62-1 X

J 9-63, 9-64 9-63, 9-64 X

J 9-65, 9-66 9-65, 9-65-1 X

3
March 1990 (Stable)

TFrrojinAiJ ALIGNMENT EDITORIAL OTHER

insert 7 - DO X

y-b/, y-D{5 Q 67 Q - 6R y

/ 10-1, 10-2 1 n 1 1 n 0

v

' 1 U - J , 1 U - if y\. Y

/ iU-_), ivJ-D

y

in"; 1 o 6 X

;10 11 in 10

y iu ii, J.U iz XU10-11XX, XU10-19XiC y

1XV^0- 1XJ, 1XV/n_ 1x*+A X

lU IJ, XU ID 1i.\J0- XJ, 1 S xv^ 10-16xo X

/ Ifl-IQ 10-90 1XV/0- 1X7,Q XV/ 10-90^V/ yvY

/ 1 O-ZiQ 1 0- "^in 1 0-ZlQ- 1 0- "^0 XU M-^ X^ JU Y

1lUO-fi'^ DJ, XU1 O-fiZi OM- 1XV^0-6"^ D-J, 1XV/0-6Zi OH y

Ifl-^^S X U D ^VlT-1l L.IIX\X X10-67 U U/ 10-6S XV/ ^VlT•ll LIIXU. 10-67 XV/ O/ A.y

! / 10-67 1 0 - 6 R 10-67 XV/ o/, 1XV/0-6Roo Y

10-71 XV/ /X, 10-79 XV/ /iL 10-71 XV/ /X, XV/ 10-79 y

10-73, 10-74 10-73, 10-74 X

, 10-77, 10-78 10-77, 10-78 X

10-83, 10-84 10-83, 10-84 X

10-85 thru 10-86 10-85 thru 10-86 X

I

4
March 1990 (Stable)

DELETE PAGE NUMBER INSERT PAGE NUMBER TECHNICAL ALIGNMENT EDITORIAL OTHER

21-5, 21-6 21-5, 21-6 X

21-7, 21-8 21-7, 21-8 X

21-9, 21-10 21-9, 21-10 X

21-11, 21-12 21-11, 21-12 X

21-13 thru 21-15 21-13 thru 21-15 X

Please retain this change page index in the back of your document

Thank you.

\

June 1990 Stable

CHANGE PAGE INDEX

VERSION 3. JUNE 1990 (STABLE) CHANGE PAGES

ISSUED SEPTEMBER 1990

OUTPUT FROM JUNE 1990 OSI WORKSHOP

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS FOR

OPEN SYSTEMS INTERCONNECTION PROTOCOLS,

VERSION 3, MARCH 1990

NIST SPECIAL PUBLICATION 500-177

This document records, in replacement page format, all changes to stable

material current (according to Version and Edition number) as of the

previous Workshop (March 16, 1990). In this case, that would be NIST SP

500-177, Version 3, Edition 1 with previous Change Pages incorporated.

By following the instructions below, and replacing or inserting the

indicated pages, text will be created which reflects the current status

of relevant stable material as of June 22, 1990.

If there are sidebars in the Table of Contents, then that document should

contain the replacement pages for June 1990. THIS INSERT SET SHOULD BE

SAVED

.

The following table gives all necessary information. Entries in the

first column indicate that those pages are to be replaced with the pages

referenced in the second column.

The instructions below are given by Chapter and Page number, referring to

NIST SP 500-177. Page numbers with extra digits are "overflow" pages to

be inserted immediately after the previously-mentioned page. The

changes made are indicated by vertical bars on the left margins of

replacement pages, and all the replacement pages are dated in the upper

right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial,

other) . The term "other" may include addition of new stable

functionality. All changes apply to the previous version and edition.

Replacements reflect the following types of changes:

1. deletion of material (blank lines)

2. insertion of new material (may lead to "overflow" pages), and

3. replacement of old text with new text (combination of (1) and (2)

above

.

Technical errata are changes from implementor experience which materially

affect the meaning or semantics of a section, and editorial changes do

not change semantics. Alignment changes are material changes made in the

interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and

alignment errata are more "severe" than technical errata. If a

1
June 1990 Stable

particular replacement has a combination of errata, the most "severe"

errata will be checked in the replacement page table. Readers should

keep in mind that these errata may be further categorized in future

editions

.
June 1990 Stable

DELETE PAGE NUMBER INSERT PAGE NUMBER TECHNICAL ALIGNMENT EDITORIAL OTHER

iii-xxvii iii-xxviii X

1-1, 1-2 1-1, 1-2 X

3-1 thru 3-18 3-1 thru 3-19 X

5-3, 5-4 5-3, 5-4 X

5-7, 5-8 5-7, 5-8 X

5-11, 5-12 5-11, 5-12 X

7-1 thru 7-4 7-1 thru 7-4 X

V Blank- 9 -4 Blank- 9 -4 X

9-9, 9-10 9-9, 9-10 X

insert 9-10-1

9-41, 9-42 9-41, 9-42 X

9-63, 9-64 9-63, 9-64 X

9-65, 9-65-1 9-65, 9-65-1 X

11-25, 11-26 11-25, 11-25-1 X

insert Blank, 11-26 X

14-1 thru 14-75 14-1 thru 14-77 X

15-1, blank 15-1, blank X

18-1, blank 18-1 thru 18-13 X

21-7, 21-8 21-7, 21-8 X

21-9, 21-10 21-9, 21-10 X

Please retain this change page index in the back of your document.

Thank you.

3

September 1990 Stable

CHANGE PAGE INDEX

VERSION 3, JUNE 1990 (STABLE) CHANGE PAGES

ISSUED DECEMBER 1990

OUTPUT FROM SEPTEMBER 1990 OS I WORKSHOP

SUPPLEMENT TO STABLE IMPLEMENTATION AGREEMENTS FOR

OPEN SYSTEMS INTERCONNECTION PROTOCOLS,

VERSION 3, SEPTEMBER 1990

NIST SPECIAL PUBLICATION 500-177

This document records, in replacement page format, all changes to stable

material current (according to Version and Edition number) as of the end

of the June Workshop, In this case, that would be NIST SP 500-177,

Version 3, Edition 1 with previous Change Pages incorporated. By

following the instructions below, and replacing or inserting the

indicated pages, text will be created which reflects the current status

of relevant stable material as of September 14, 1990.

If there are sidebars in the Table of Contents, then that document should

contain the replacement pages for September 1990. THIS INSERT SET SHOULD

BE SAVED.

The following table gives all necessary information. Entries in the

first column indicate that those pages are to be replaced with the pages

referenced in the second column.

The instructions below are given by Chapter and Page number, referring to

NIST SP 500-177. Page numbers with extra digits are "overflow" pages to

be inserted immediately after the previously-mentioned page. The

changes made are indicated by vertical bars on the left margins of

replacement pages, and all the replacement pages are dated in the upper

right-hand corner for easy identification.

Changes on replacement pages are Errata (technical, alignment, editorial,

other) . The term "other" may include addition of new stable

functionality. All changes apply to the previous version and edition.

Replacements reflect the following types of changes:

1. deletion of material (blank lines)

2. insertion of new material (may lead to "overflow" pages), and

3. replacement of old text with new text (combination of (1) and (2)

above

.

Technical errata are changes from implementor experience which materially

affect the meaning or semantics of a section, and editorial changes do

not change semantics. Alignment changes are material changes made in the

interest of international harmonization and evolving base standards.

In general, technical errata are more "severe" than editorial errata, and

alignment errata are more "severe" than technical errata. If a

1
September 1990 Stable

particular replacement has a combination of errata, the most "severe"

errata will be checked in the replacement page table. Readers should

keep iri mind that these errata may be further categorized in future

editions

.

2
September 1990 Stable

UbU^Ih. PAGE NUMBER INSERT PAGE NUMBER TECHNICAL ATT /TKTU"I7'fcTT ALlGNMENi 17T\ T ffW} TAT UirlrJv

^ iabie or Contents Table of Contents VA

/ Lnapter i Chapter 1 AY

0 1 0 0 z - i - AA

O 1 o o z - 1 , z - Z AY

"3 1 TO ^ 3-1, 3-2 3-1 , 3-2 AY

^4-1, 4-2 4- 1 , 4-2 AV

5 - 3 , 5-4 5-3, 5-4 A

y 5-13, 5-14 CIO C 1 / 5-13 , 5-14 A

y Insert 5-14-1 AV

^ 5-25, 5-26 J-ZJ, j-zo AV

/

/ O "7 cr o O ^ J-Z/, J-ZO ^ O "7 O Q J - z / , D - Z<5 AY

o - J , 0-4

V Q "3 Q /, 0 - J , 0-4 YA

^insert 8-4-1 A

yon 0 1 A ^/o-y, o-iU 0Q Q 0 1 n - y , 0 - iu AY

Q 0 1 (3 0 0 o-zi, o-zz C 0 1 Q 0 0 o-Zi, 0-Zz AY

o-jy, o-bu o-jy, o-t)(j AY

O-DJ, O-DO ODJ, 8-^;'^ 8-fi<^ ODD AY

DianK, y-4 DianK, y-4 AV

11 OC 11 Ot^l ll-z5, il-zj-i 11 01^ 11 Oc:i ii-zD, ii-ZJ-i VA

11 ^1 11 ^o 11-61 , 11-62 ^ ,

11 c^ 11 iio ii-Oi, ii-DZ VA

11-63 11-64 11-63, 11-64 X

11-65, 11-66 11-65, 11-66 X

11-67, 11-68 11-67, 11-68 X

11-69, 11-70

iL-.: : — 11-69, 11-70 X
September 1990 Stable

DELETE PAGE NUMBER INSERT PAGE NUMBER TECHNICAL ALIGNMENT 1 EDITORIAL OTHER

11-71, 11-72 11-71, 11-72 X

14-3, 14-4 14-3, 14-4 X

14-13-14-20 14-13-14-20 X

insert 14-20-1

14-53, 14-54 14-53, 14-54 X

insert 14-54-1 X

14-57-14-60 14-57-14-60 X

insert 14-60-1 X

14-65, 14-66 14-65, 14-66 X

Chapter 20 Chapter 20 X

4
N'ST-il4A U.S. DEPARTMENT OF COMMERCE

(REV. 3-89) NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

BIBLIOGRAPHIC DATA SHEET

1. PUBLICATION OR REPORT NUMBER NIST/SP-500/177

PERFORMING ORGANIZATION REPORT NUMBE

3. PUBLICATION DATE March 1990

4. TITLE AND SUBTITLE

STABLE IMPLEMENTATION AGREEMENTS FOR OPEN SYSTEMS INTERCONNECTION PROTOCOLS

Version 3 Edition 1 December 1989

5. AUTHOR(S)

Tim Boland, Editor

6. PERFORMING ORGANIZATION (IF JOINT OR OTHER THAN NIST, SEE INSTRUCTIONS)

U.S. DEPARTMENT OF COMMERCE

NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY

GAITHERSBURG, MO 20899

7. CONTRACT/GRANT NUMBER

!8. TYPE OF REPORT AND PERIOD COVERED

Final

9. SPONSORING ORGANIZATION NAME AND COMPLETE ADDRESS (STREET, CITY, STATE, ZIP)

Same as Item #6

10. SUPPLEMENTARY NOTES

Supersedes NIST/SP-500/162

I DOCUMENT DESCRIBES A COMPUTER PROGRAM; SF-ISS, FIPS SOFTWARE SUMMARY, IS ATTACHED.

1 1 . ABSTRACT (A 200-WORD OR LESS FACTUAL SUMMARY OF MOST SIGNIFICANT INFORMATION. IF DOCUMENT INCLUDES A SIGNIFICANT BIBLIOGRAPHY 01 LITERATURE SURVEY, MENTION IT HERE.)

This docuitient records current Stable Agreements for Open Systems Interconnection

Protocols among the organizations participating in the NIST/OSI Workshop Series

for Implementors of OSI Protocols.

12. KEY WORDS (6 TO 12 ENTRIES; ALPHABETICAL ORDER; CAPITALIZE ONLY PROPER NAMES; AND SEPARATE KEY WORDS BY SEMICOLONS)

Local Area Networks; Network Protocols; NIST/OSI Workshop; Onen Systems Interconnection;

Testinn Protocols

13. AVAILABIUTY 14. NUMBER OF PRINTED PAGES XX UNUNITED

FOR OFFICIAL DISTRIBUTION. DO NOT RELEASE TO NATIONAL TECHNICAL INFORMATION SERVICE (NTIS). 679

XX

ORDER FROM SUPERINTENDENT OF DOCUMENTS, U.S. GOVERNMENT PRINTING OFFICE, WASHINGTON, DC 20402. ORDER FROM NATIONAL TECHNICAL INFORMATION SERVICE (NTIS), SPRINGFIELD, VA 22161.

15. PRICE

ELECTRONIC FORM

ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SYSTEMS TECHNOLOGY

Superintendent of Documents

Goveniment Printing Office

Washington, DC 20402

Dear Sir:

Please add my name to the announcement list of new publications to be issued in

the series: National Institute of Standards and Technology Special Publication 500-.

Name

Company

Address

City State Zip Code

(Notification key N-503)

sJr U.S. GOVERNMENT PRINTING OFFICE: 1990 — 261- 913/ 20518



1 1 A^Sj Technical Publications

Periodical

Journal of Research of the National Institute of Standards and Technology—Reports NIST research

and development in those discipHnes of the physical and engineering sciences in which the Institute

is active. These include physics, chemistry, engineering, mathematics, and computer sciences.

Papers cover a broad range of subjects, with major emphasis on measurement methodology and

the basic technology underlying standardization. Also included from time to time are survey articles on topics closely related to the Institute's technical and scientific programs. Issued six times a year.

Nonperiodicals

Monographs—Major contributions to the technical literature on various subjects related to the

Institute's scientific and technical activities. Handbooks—Recommended codes of engineering and industrial practice (including safety codes) developed in cooperation with interested industries, professional organizations, and regulatory bodies.

Special Publications—Include proceedings of conferences sponsored by NIST, NIST annual reports,

and other special publications appropriate to this grouping such as wall charts, pocket cards, and

bibliographies.

Applied Mathematics Series—Mathematical tables, manuals, and studies of special interest to physicists, engineers, chemists, biologists, mathematicians, computer programmers, and others engaged in

scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical

properties of materials, compiled from the world's literature and critically evaluated. Developed un- der a worldwide program coordinated by NIST under the authority of the National Standard Data

Act (Public Law 90-396). NOTE: The Journal of Physical and Chemical Reference Data (JPCRD)

is published quarterly for NIST by the American Chemical Society (ACS) and the American Insti- tute of Physics (AIP). Subscriptions, reprints, and supplements are available from ACS, 1155 Sixteenth St., NW., Washington, DC 20056.

Building Science Series—Disseminates technical information developed at the Institute on building

materials, components, systems, and whole structures. The series presents research results, test methods, and performance criteria related to the structural and environmental functions and the

durability and safety characteristics of building elements and systems.

Technical Notes—Studies or reports which are complete in themselves but restrictive in their treat- ment of a subject. Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often serve as a vehicle for final reports of work performed at NIST

under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The standards establish nationally

recognized requirements for products, and provide all concerned interests with a basis for common

understanding of the characteristics of the products. NIST administers this program as a supplement

to the activities of the private sector standardizing organizations.

Consumer Information Series—Practical information, based on NIST research and experience, covering areas of interest to the consumer. Easily understandable language and illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order the above NISTpublications from: Superintendent of Documents, Government Printing Office,

Washington, DC 20402.

Order the following NISTpublications—FIPS and NISTIRs—from the National Technical Information

Service, Springfield, VA 22161.

Federal Information Processing Standards Publications (FIPS PUB)—Publications in this series col- lectively constitute the Federal Information Processing Standards Register. The Register serves as the official source of information in the Federal Government regarding standards issued by NIST

pursuant to the Federal Property and Administrative Services Act of 1949 as amended. Public Law

89-306 (79 Stat. 1127), and as implemented by Executive Order 11717 (38 FR 12315, dated May 11, 1973) and Part 6 of Title 15 CFR (Code of Federal Regulations).

NIST Interagency Reports (NISTIR)—A special series of interim or final reports on work performed

by NIST for outside sponsors (both government and non-government). In general, initial distribu- tion is handled by the sponsor; public distribution is by the National Technical Information Service,

Springfield, VA 22161, in paper copy or microfiche form.
U S. Department of Commerce

National Institute of Standards and Technology

(formerly National Bureau of Standards)

Gaitfiersburg. MD 20899

Official Business

Penalty for Private Use $300