ment concerning addressing is not reach-

ed, we will have to regard the separate X.400 implementations as separate systems with gateways between them. Users may then see addresses with dif-

ferent structures, and we need an ad- ministration able to handle a lot of gateways.

If an agreement can be reached, the users will see a harmonized addressing space and there will be no gateways within the RARE MHS service.

4. The X.400 Activity and RARE Membership

In view of what has been said above, the RARE MHS activity will also in-

fluence the issue of RARE membership. Some message service providers may

choose to stay outside the RARE com- munity, either because there exists no migration plan, or they may decide to organize a separate X.400 service with a

separate management . The addressing space may differ f rom RARE, and inter- working must be treated as a special case in spite of common X.400 protocols. In-

deed, this will not benefit the users, and is

therefore not recommended. RARE should encourage all message

service providers in the R&D area to join either the national RARE organizations, and thereby be a part of RARE together with the full national members, or to join RARE as international members, thereby affirming the objectives of RARE.

References

[1]. Alf Hansen et al: Documentation of the R&D MHS Service.

[21. CCITT: X.400, Message Handling System: System Model-Service Elements. X.411, Message Handling System: Basic Ser- vice Elements and Optional User Facilities. X.420, Message Handling System: Interper- sonal Messaging User Agent Layer. X.409, Message Handling System: Presenta- tion Transfer Syntax and Notation. X.408, Message Handling System: Encoded In- formation Type Conversion Rules. X.430, Message Handling System: Access Pro- tocol for TELETEX Terminals. X.410, Message Handling System: Remote Operation and reliable Transfer Service.

Functional Standards Paul Bryant Rutherford Appleton Laboratory, Chilton, Didcot, Oxon, 0X11 OQX, England

The ISO communicat ions standards

have progressed to the point where it is becoming possible to provide products based on them. It has become apparent that since these standards have many op- tions, it is easy to produce products which conform to the standards, but which can- not interwork. The purpose of a ' func- t ional ' standard is to impose restrictions on implementations of sets of protocols to ensure that they will interwork. C E N / C E N E L E C , the European stan- dards body, and CEPT, the advisory organization for the European PTTs, have set up a work item to produce func- tional standards primarily for use within Europe. This paper outlines the history and organization of the activity. It defines how far the work has progressed and how it is likely to progress.

History

It was in the Autumn of 1984 that C E N / C E N E L E C (the European stan- dards organizations) and CEPT (the ad- visory committee for the European PTTs) agreed to produce a range of func-

tional standards for use within Europe. In 1983/84 the European Commission

hosted a number of meetings aimed at harmonizing the use of communicat ions protocols, particularly in the academic field. This was commonly known as the Zander initiative as the work was initially proposed by Professor Karl Zander of Hahn-Meitner Institut, Berlin. This work resulted in the COS (Common use of OSI Standards) documents which dealt with: Connection mode network layer COS-I Transport layer COS-2

Local area networks COS-3

Tripe X (the X.3, X.28, and X.29 recom-

mendations) COS-4 The work was, perhaps, a little premature and little practical use was made of it, particularly as the funds 'dried up' and there was no early follow up. However, the work was not in vain as it was adopted by SPAG which produced the GUS (guides to the use of standards). This group extended the work to cover many more protocols; in fact, it was almost a total cover of the popular pro-

to~ols expected to be in common use and issued as standards or recommendations

by one or another of the standards bodies. By this time it had become clear that

' interpretat ion' , 'harmonizat ion ' , and ' interworking' were important issues which ISO was not addressing. Effective products in a multi vendor environment require far more than the basic stan- dards- they require documents on how these standards should be used in specific situations. The standards were designed

to be all things to all men whereas the customer wanted some very specific ser-

vices. Thus the term 'functional stan- dard ' was coined to cover this area.

A functional standard specifies the ap- plication of one or more standards in sup- port of a specific requirement for communicat ion between computer sys- tems. It does not alter the standards to which it refers, but makes explicit the relationship among a set of standards us- ed together and may also specify choices

of options and values of parameters to be

used. A document of agreement setting up

the co-operation between C E N / C E N E - LEC and CEPT is known as H D 40 001. The overall responsibility of the work lies with SOGITS (the Senior Officials Group for Informat ion Technology Standards) which is a committee of the European Commission which directs C E N / C E N E L E C in this area and a similar group in CEPT. At the next level

there is ITSTC (Information Technology Steering Committee) which is responsible for the political direction of the work. Next is ITAEGS (Informat ion Technol- ogy Ad Hoc Experts Group) which monitors the technical progress of the work. This committee has represen- tatives f rom C E N / C E N E L E C , CEPT and the chairmen of the working groups also attend. Each of the functional stan- dards has a working group associated

106

with it which is either run by C E N / C E N E L E C with observers f rom

CEPT or is run by CEPT with observers f rom C E N / C E N E L E C .

ITAEGS ' first task was to produce M- IT-01. This is a memorandum defining the terms of reference of the activity. This T is more or less complete. The group is A now dealing with the technical issues be- Q, S tween groups and also planning the R future programme. Y

C

The Work Program

SPAG had produced a large list of potential functional standards in their documents. This was adopted. Priority items were selected and formed the basis

of a document M-IT-02 which was a list of the work items. This document is con- tinually being modified to reflect the work of the working groups and the addi- tion of new work items.

Working Methods

Each of the working groups has met on several occasions to produce working draft functional standards and eventual- ly drafts for 'vot ing ' . The final draft is then distributed to the member bodies and a period of three months is allowed planned: for comment. Voting on the draft takes A/11 place at a meeting and there is a fairly A/3xx complicated set o f rules to ensure that the process is ' fa i r ' . The resulting document C / I lx becomes an ENV (European Pre Norm). Q/241

During theinitial stages of the activity, T/32, ITAEGS produced drafting recommen- T /4x l dations to ensure that the documents achieve a uniform quality of presenta- T/611 tion. For example, the first few chapters have identical headings in each standard T/622x and even the content of these chapters is controlled. The later chapters are less R / l x ,

constrained, but nonetheless care has to R/2x be taken with the language to ensure that the meaning of the text is clear and unam- biguous.

Unlike an ISO standard, a functional standard may include as appendices tutorial material and advice for im- A/231, plementors. This is indicative of the fact 241 that a functional standard is likely to be A/325 used by implementors and there is merit C/13x in attempting to influence implementa- Q/113-4 tions in following certain good practices. Q/22x The tutorial and advice information is T /2x not part of the functional standard and T/621 need not necessarily be followed.

Work in Progress

Each functional standard is designated by a code (a scheme invented by SPAG). The first letter signifies the type of func- tional standard:

Layer 1-4 Layer 5-7 Content, Repertoires Relay Non OSI

Telematic combinations

The initial functional standards are: T/621x C S M A / C D Connection less

C E N / C E N E L E C T/3 l x Transport service over X.25

CEPT

A/31x Access to public MHS CEPT A/32x Access to private MHS

C E N / C E N E L E C Y / l l / 1 2 X.3, X.28, and X.29

C E N / C E N E L E C Q/21 x Character-coded text

C E N / C E N E L E C A/221 Teletex CEPT It is expected that functional standards for these will be voted on by the middle of the year.

A second set of work items is now being

FTAM MHS access protocol (P3 and

P5) Teletex service Videotex content

Connections to wide area net- works

C S M A / C D connection oriented network service

Token bus connection less network service

Relays between connection less connection network service

A third set of work items is being planned to start at the end of 1986:

Teletex FAX mixed mode MHS access P7 Mixed mode service Mixed mode formats Mixed mode content Telephonic WAN Token bus connection

oriented network service

The above two lists are subject to change.

It is interesting to note that the split be- tween 'high' and ' low' level protocols is at the top of transport level. There is an

argument that it would be better made at the top of network level. The reason for the current split is historic in that when the work started transport had a far more stable definition than network and thus

this division was less confusing. A deci- sion now would probably favour net- work layer.

Relationship with Other Bodies

There are a number of other similar ac-

tivities. In particular the National Bureau of Standards Open Systems Workshop is undertaking similar work in a rather dif- ferent way. So far liaison has been by

means of participation in their work by a few people also involved in the functional standards. It is important that eventually the results are harmonized if differences in European and American products are to be avoided. ITAEGS is considering ways of closer co-operation with America.

The MAP (use of OSI in manufactur-

ing), TOP (use of OSI in office automa- tion) and COS (Corporat ion for Open Systems) projects are rather more like the SPAG. This is because the work is manufacturer and /o r product led. Nonetheless, their work is closely associated with functional standards.

There is a real problem in ensuring that all these groups eventually agree upon common functional standards.

Conformance

It is expected that manufacturers will produce equipment that conforms to the functional standards. Such conformance claims need testing if the customer is to be certain that he can believe the manufac- turers' claims. Also a manufacturer needs to have his equipment tested to en- sure the quality of his product. To this end a number of contracts have been let to develop conformance testing centres. Eventually this should lead to the cer- tification of products.

Fairly detailed plans for certification by CENCER (the CEN certification organization) have been drawl~ up. So far it is not clear when these centres will be

107

available and when certified products will be available.

Other Activities

Recently the I T A E G M (Information Technology Ad Hoc Experts Group in Manufacturing) has been set with similar terms of reference to ITAEGS, but in the manufacturing area. This work is closely associated with the MAP and TOP ac- tivities.

One would not use OSI standards for

procurement because of the vast array of options. Functional standards are closer to a procurement standard, but even then these are insufficient in that a piece of equipment needs to conform to other things, for example, a functional stan-

dard applied to a start-stop mode DTE

does not demand that it has a

keyboard-let alone one with particular

characteristics. Thus there is probably a further level of abstraction f rom the functional' standards to produce procure- ment ones.

Relevance to RARE

The success or failure of RARE depends on interworking between dif- ferent products on different networks in

different countries. Thus functional standards are of vital interest. It is most

important that an interest is taken in the documents at an early stage when input can be made to ensure that they meet the requirements of the community and are also of a high quality.

FTAM Tutorial P. F. Linington Chairman of RARE, Joint Network Team, c/o Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire, UK

The ISO standard for File transfer, Ac- cess and Management (ISO 8571) is now at the stage of a Draft International Stan- dard, undergoing the last ballot before it becomes a full standard. This has been

made possible by a coordinated effort to accelerate it together with the group of supporting standards so that the com- plete set necessary for file applications are published together.

The FTAM standard consists of four parts. The first gives a general introduc- tion, describing the concepts and mechanisms involved in the standards. The second defines a virtual filestore, enabling users to describe many different types of file storage in common terms. This concept of a single abstract defini- tion of what a filestore looks like is essen- tial for the open manipulation of files.

The last two parts deal explicitly with communication. The third part defines the service which an implementation of the standard will provide, and thus tells the user of FTAM what he will be able to achieve when planning to use FTAM in distributed applications. Finally, the fourth part specifies the protocol- the ac-

108

tual communicat ion exchanges which are

to take place between systems in order to provide the target file service. It is on the basis of the statements in this part that the correctness of an implementation will

be tested. The FTAM standard provides a

general purpose toolkit for the manipula- tion of files. The most basic capability is the transfer of a single file, with the minimum of preliminary dialogue. However, functions can be added to manage files, interrogating or changing their properties as necessary. If required, access can also be made to parts of a file, possibly holding the file open while a number of different sections are read or written. I f access is to a public file, various parts can be read before changing the way the file is opened so that exclusive control is taken for selective updating.

In addition to this variety in the types of activity undertaken, there are a wide range of supporting mechanisms, con- trolling charging and accounting, access control, concurrency control, distributed commitment and many other user facilities. For system designers, there are

error recovery mechanisms to correct for communicat ion or host errors. The ap-

plication designer can select the features he needs f rom this toolkit.

This richness of facility is managed by a succession of selection mechanisms, so

as to avoid the risk of failure of com- munication arising f rom incompatible selection of options. First, the standard

defines a few services classes correspon- ding to the major types of application ac- tivity: file transfer, file access and file

management . Selection of the ap- propriate service class characterizes the

actions to be undertaken. Within this constraint, the communicat ion function is divided into a number of well defined functional units, which are negotiated

between the two systems to establish a shared set of capabilities. The set of func- tional units agreed in each instance deter- mines the range of the subsequent dialogue.

Separately, the two parties negotiate which of a set of attribute groups shall be valid, determining which properties of the filestore can be manipulated.

Much of the standard is concerned with the specification and manipulation of file contents. It covers the structure

and constraints on the filed data and the types of information which can be stored.

First, a structural model for file con- tents is defined. This is a general hierar- chical model, allowing data to be organized into a rooted tree, a powerful structure capable of describing many file types. Specific files are instances of this general structure, obtained by applying a particular set of structural constraints. The constraint sets defined in the stan-

dard cover very simple unstructured files-the trivial case of a h ie rarchy-and traditional sequential files-hierarchies with only one level below the root. They also identify more complicated special cases such as the structure of a multi- indexed file.

This structuring information controls the way the file contents may be accessed, and the type of identification which may be used to select the file access data units. However, it does not constrain the stored data within these units. Further informa- tion is needed to give the abstract syntax of the data stored, and the protocol pro- vides the mechanisms to transfer statements of the name of the abstract syntax to which the file contents con-