Automatic protocol generation based on x.409 specifications

North-Holland Microprocessing and Microprogramming 24 (1988) 111-120 111

AUTOMATIC PROTOCOL GENERATION BASED ON X.409 SPECIFICATIONS *

Patrick M.J. Hellemans and Hubert J.M. Decuypere

Bell Telephone Mfg Co F. Wellesplein 1

B-2018 Antwerp, Belgium

In recommendation X.409 the CCITT presents a standardised presentation and representation technique to define the data units that constitute the different x .400 protocols. Apparently, the X. 409 recommendation will have a much broader field of application and will be used for a large number of application layer protocols. The machine processable nature of the X.409 specification language clearly demands for a software development environment. This paper introduces the tools developed at the Bell Telephone Mfg Co Research Centre to support the implementation of protocols based on an x. 409 specification. The key of the protocol development environment is the generation of a PASCAL data structure as the internal representation of an X.409 protocol. A protocol specified in x . 409 will yield an equivalent instantiation of such a datastructure. Based on this protocol representation, part of the protocol entity can be implemented automatically.

1. INTRODUCTION 2. X.409

Protocol specifications and implementations will become an important activity for those involved with telecommunication. In the light of this evolution, the availability of a protocol development environment is a major asset. The work done on tools to automate the implementation of protocols specified in X.409 must be seen in this context.

In the next section, we get acquainted with X.409 and the underlying principles. In section 3. we pro- pose an architecture for protocol entities which will permit automated protocol implementations. In sec- tions 4. and 5. both the off-line and the run-time part of the development environment are discussed. A simple example is given to illustrate the protocol implementation procedure.

In a last section, we stress the importance of protocol development environments in view of the present evolution in the communication business.

2.1. Application layer protocols

In the x .400 series of recommendations the CCITT presents a standardised electronic mail service here- after referred to as the Message Handling System (MHS). MHS is based on the layered Reference Model of Open Systems Interconnection for CCITT applications [1]. Figure 1 gives a pictorial illustration of the osI Model.

APPLICATION LAYER

PRESENTATION LAYER

SESSION LAYER

TRANSPORT LAYER

NETWORK LAYER

DATA LINK LAYER

P H Y S I C A L L A Y E R

A P D U

P P D U

S P D U

T P D U

APPLICATION LAYER

P R E S E N T A T I O N LAYER

SESSION LAYER

TRANSPORT LAYER

NETWORK LAYER

]DATA LINK LAYER

PHYSICAL LAYER

Figure 1: OSI model

*This work was partly funded by the IWONL (Instituut voor Wetenschappelijk Onderzoek in Nijverheid en Landbouw}, Belgium

One of the concepts of the reference model is the peer- to-peer protocol, whereby information is exchanged between different entities within the same layer. This

112 P.M.J, Hellemans, H.J.M. Decuypere /Automatic Protocol Generation Based on X.409 Specifications

information is wrapped up in data packets called protocol data units (PDU's).

In the lower layers up to and including the session layer, these data units are of a 'structurally simple' nature. The CCITT has taken the view that the data units that constitute the different X.400 protocols will be defined and represented in a much more struc- tural manner. In fact the structure of the protocol data units will be comparable to the data types that can be defined in modern high level programming lan- guages like PASCAL. Therefore, they can be subject to comprehensive syntactical checks.

2.2. Standard notation and representation

In recommendation X.409 [3] the CCITT presents a standardised specification technique for application layer protocols. Two different notions are clearly dis- tinguished.

Standard Notation denotes the syntax of the language that shall be used to specify the Application Protocol Data Units (APDU's).

Standard Representation fixes the exact rules how the APDU's are to be encoded as a series of octets.

In terms of a high level programming language, we can view the syntax of the language as the Stan- dard Notation and the code generated by compilers for that language as the representation of it. How- ever, we cannot say that this representation is in any way standardised. It is not guaranteed that different compilers encode language components in the same way - - different number of bytes, different order of the bytes.

This is a problem when implementing protocols since the information exchanged between peer entities shall be encoded in the same way to ensure mutual under- standing. X.409 does not suffer from this. The Stan- dard Representation part of it provides a set of rules which permits exact encoding of APDU's as a stream of bytes. Each value of any type shall be represented by three components of variable length:

1. The Identifier-Field which uniquely identifies the type.

2. The Length-Field which denotes the number of bytes of the Contents-Field.

3. The Contents-Field to represent the actual contents of the information.

2.3. Types and values

An important concept defined in X.409 is that every piece of information contained in an APDU shall have a type as well as a value associated with it and that both shall be carried by the APDU. The APDU itself can be regarded as a unit of information. Its associated type and value would be ordered lists of the types and values of the components of the APDU.

The philosophy behind the concept of a type in X. 409 is very much the same as in PASCAL. The recommendation presents a list of built-in types out of which new types can be defined. This can be compared to the declaration of PASCAL types where one can define new types in terms of built-in types like INTEGER, BOOLEAN, RECORD, ARRAY, . . . .

We won't go into a detailed description of all the aspects concerning X.409 types. Especially in view of the important upgrade of the recommendation in the 1988 version this information would rapidly become obsolete.

2.4. A simple example

Suppose a bank client is characterized by the com- bination of his surname and his bank account. His Christian name may optionally be provided. A client could be defined by the following X. 409 standard notation.

Client : := SEQUENCE{

christianName [ O] IMPLICIT PrintableString OPTIONAL,

surname

[ i] IMPLICIT PrintableString,

BankAc count }

BankAccount : :=

NumericString

PrintableString and NumericString are defined in the standard in terms of the built-in type OCTET STRING.

PrintableString : :=

[ UNIVERSAL 19] IMPLICIT OCTET STRING NumericString : :=

[ UNIVERSAL 18] IMPLICIT OCTET STRING

If we draw the analogy towards PASCAL the client can be looked upon as being the counterpart of a variable of type BankClient.

TYPE

YrintableString = PACKED ARRAY [ I.. 100] DE CHAR;

NumerlcString = PACKED ARRAY [ i..I00] OF CHAR:

P.M.J. Hellemans, H.J.M. Decuypere / Automatic Protocol Generation Based on .)(.409 Specifications 113

BankAccount = NumericString;

BankC1ient =

RECORD

christianName : PrintableString;

surname : PrintableString;

account : BankAccount

END;

The value for a particular individual could be :

christianName : 'Tony'

surname : 'Parker'

BankAccount : '789 6430288 17'

Figure 2 illustrates the octet-level encoding of this value according to the X.409 standard representa-

tion rules (each octet is denoted by two hexadecimal

digits).

I 30 1E 80 04 54 6F 6E 79 81 06 50 61 72 68 65 72 [ 12 0E 37 38 39 20 35 34 33 30 32 38 38 20 31 37 L

I D F i e l d o f L e n g t h i n S e q u e n c e o c t e t s

1 E

C o n t e n t F i e l d of the

S e q u e n c e

I D F i e l d o f in [ 0 ] I M P L I C I T C o n t e n t F i e l d

o c t e t l P r l n t a b l e S t r l n g

' T ' 'o ' Ln' ' y ' 80 04

5 4 6F 6 E 70

I D F i e l d o f L e n g t h i n

[ 1 ] I M P L [ C I T C o n t e n t F i e l d o c t e t s

p r l n t a b i e S t r i n g

g l 06 ' P ' 'a ' ' r ' ~k' 'e ' ' r ' 30 61 72 6 8 65 72

I D F i e l d of N u m e r i c L e n g t h i n C o n t e n t F i e l d

S t r i n g octet~

'3~'' '7 ' ' s ' '3 ' ' g ' '3 ' 37 38 2 0 3 3 3 4 3 3

12 0 E ' 0 ' ' 2 ' ' 8 ' , s ' ' ' ,1 ' ,7' 3 0 32 3 8 3 8 2 0 31 3 7

Figure 2: Standard representation of an APDU

3. x . 4 0 9 BASED PROTOCOL IMPLEMENTATION

In view of the growing interest in communication applications, the development of communication protocols is becoming a major occupation both for communication equipment suppliers and for the service providers. In spite of the importance of the activity and the investments involved, only few supporting tools are available to automate this activity.

The toolset described in this paper is a starting point. It covers only part of the different stages of the protocol development and implementation cycle. However, it must be stressed that the tools are based on X.409

specifications. It is indeed important to have a stan- dardized specification method as the basis since it is likely that in the future communication protocols will be published in a standardised language.

3.1. Philosophy

The development of new communication protocols in- volves two activities. In the design and specification phase, one is primarily concerned with properties of the protocol like consistency, completeness, validity, absence of deadlocks, liveness, . . . . Later on, the protocol must be implemented in a specific environment. Here, it is important to have tools which support automated implementations.

The development environment we talk about is mainly intended to facilitate the flexible implementation of protocols, but to some extent also supports the design and specification of new protocols. The key issue in the environment is the representation of application layer protocols as PASCAL data structures. This has been inspired by the analogy between APDU's and PASCAL data structures.

The off-line part of the environment permits to val- idate X.409 specifications syntactically and to pro- duce representations of the specified protocol. The on-line part of the environment uses these representations to implement specific functions of the protocol entity.

3.2. Architecture

To be able to automate the implementation of proto-

col entities, a standard architecture for such an entity is adopted (see figure 3). Three basic functions are defined.

Validation Procedure

Receives a bytestream from a peer entity, checks it for valid encoding and produces a data structure, the value of which represents the contents of the incoming bytestream.

J~in f l~ %in

Protocol Machine

May be viewed as a finite state machine which, given a state acid and an incoming protocol data unit r i , , produces an outgoing protocol data unit ~out and goes to a new state a,ew.

114 P.M.J. Hellemans, H.J.M. Decuypere / Automatic Protocol Generation Based on X.409 Specifications

Construction Procedure Checks the values in the data structure produced by the protocol machine and encodes it according to the X.409 rules, resulting in an outgoing bytestream.

¢ 7Tou, ~ ~out

The functional blocks are linked to each other via the PASCAL representation of the APDU's.

I protocol machine

T I APDU

representation (PASCAL)

V . . . . . . . . . proce, dure ~--~ ~_~G . . . . . . pro¢~dureOTlON byt~gotori~gml w

Figure 3: Architecture of a protocol entity.

The development environment aims at automating the implementation of the validation procedure, the construction procedure and to provide a framework for the implementation of the protocol machine. Up to now, only the validation and construction procedures have been implemented.

Both procedures are conceived as parameterised components. The algorithm part is a generic software system component. The specific behaviour of the procedures is encoded in a data structure representing the specific protocol. This data structure is generated automatically out of the X.40g specification by the off-line environment. If we call this protocol representation P, we can write the validation and the construction procedure as follows.

It is our intention to base the implementation of the protocol machine J~ on the same principle.

3.3. System architecture

Typical communication and service providing systems support multiple application layer protocols. The above described architecture is well suited for such systems.

The generic validation and construction procedures must be viewed as special purpose processors which are part of the basic resources of the system. These processors are shared by all application protocol entities. Each protocol entity in the system only contains the protocol desciption in the form of a PASCAL data structure. To implement new protocols, it is sufficient to introduce the representation of the protocol in the system. Figure 4 gives an impression of the proposed architecture for the application layer of such a communication system.

i APDU E ', Representatlon i : (PASCAL)

byte#lream ~ t ° ¢ ° l m 2 : : : : : : : : : : : : : : : CONSTRUCTION ~1 entlty ', ~ procedure

\ ', Protocol : i Representation ', i ! P . . . .

', RepreJentation 1

byteotream protocol_l : " Generic ::.':_-_-_-_-_-:::::_-~ VALIDATION 4 a tity , , procedure ', Protocol ', ', Representation ',

Figure 4: System architecture.

4. THE OFF-LINE ENVIRONMENT

This part of the protocol development environment both supports the design and specification of new application layer protocols and produces the necessary information needed by the run-time environment.

A technique has been developed to represent X.40g protocols in the form of a PASCAL data structure.

LILA [9] has been used to generate an X.409 parser/compiler for the Standard Notation. It takes an X.40g specification as input. The parser not only checks the correctness of the specification but it also generates its representation as a PASCAL data structure. Furthermore it declares the global variables that will hold the value of the information contained in the APDU's. The names of these variables are automatically generated based on information in the x .40g specification. Finally, it produces documentary in-

P.M.J. Hellemans, H.J.M. Decuypere /Automatic Protocol Generation Based on X.409 Specifications 115

formation concerning the PASCAL representation in a user friendly format.

Protocol Specified in X.400

f X.40O Parser/Compiler

', Diagnostic File *,

Protocol representation

(PASCAL)

APDU repreleatation (PASCAL)

Protocol representLtion (user friendly)

The validation procedure is implemented in PASCAL as a function which returns a boolean value indicating the validity of the bytestream.

FUNCTION ValidX409ByteStream (

IncomingByteStream : Data;

Structure : ROMPtX409Element)

: B O O L E A N ;

IncomingByteStream represents an incoming octet string of arbitrary length.

Structure represents the protocol internally.

Figure 5 : X . 4 0 9 parser/compiler

5. THE RUN-TIME ENVIRONMENT

The run-time environment is a set of generic system resources. These are parameterised software components. Their specific behaviour is controlled by the protocol representation which has been produced by the off-line environment.

5.1. The VALIDATION procedure

The role of the Validation Procedure is to check the validity of an incoming bytestream and to initialise global PASCAL variables which hold the information present in the incoming APDU.

This Validation Procedure is a generic procedure. Its specific behaviour is controlled by the protocol specification. Therefore, the input for this procedure are

1. the protocol specification in the form of a PASCAL data structure

2. an incoming stream of bytes representing a data unit of that protocol, encoded according to the X.409 encoding rules.

The procedure

1. checks the correctness of the incoming stream of bytes

2. initializes the global variables that hold the information present in the APDU.

PASCAL reprementLtlon

ofth¢ protocol

incomlng byteBtre~m

£"

incoming ~, bytestre~m

Figure 6: VALIDATION procedure

5.2. The CONSTRUCTION procedure

The role of the Construction Procedure is to pro- duce an outgoing bytestream encoded according to the x. 409 specifications. It checks whether the global variables are legally initialized and generates an outgoing bytestream.

This Construction Procedure again is a generic procedure who's specific behaviour is controlled by the same protocol specification as the Validation Proce-

dure.

Therefore, the input for this procedure are

1. the protocol specification as a PASCAL data structure

2. the initialized global variables that represent the information present in the APDU.

The procedure

1. checks if the values stored in the global variables are legal

116 P.M.J. Hellemans, H,J.M. Decuypere / Automatic Protocol Generation Based on X.409 Specifications

2. generates a bytestream encoded according to the x. 409 rules, corresponding with the APDU hold by the global variables.

The construction procedure is implemented in PAS- CAL as a function which returns a boolean value indicating the validity of the values in the global variables.

FUNCTION Const ructX4OgByt eStream (

VAR OutgoingByteStream : Data;

Structure : ROMPtX4OgElement)

: BOOLEAN ;

OutgolngByteStream represents an outgoing octet string of arbitrary

length.

Structure represents the protocol internally.

representLtlon of the

#~cce#,

I I ,: .... ;;,:-:j- ', i u i t i a l i s ed *,

valuem L . . . . . . . . . . . . . . . . !

ou£going j byt~s~ream

Figure 7: CONSTRUCTION procedure

5.3. Example protocol

5.3.1. Protocol specification

We pick up our previous example of the bank. The protocol specification in the X.409 syntax (as it is known to the parser) is given by:

BANK DEFINITIONS : : =

BEGIN

Order ::= CHOICE{ RaiseCredit,

LowerCredit};

RaiseCredit ::=

[ APPLICATION I] SET{ Client,

amount INTEGER};

LowerCredit ::= [ APPLICATION 2] SET{ Client,

amount INTEGER};

Client ::= SEQUENCE{

christianName

[ O] IMPLICIT PrintsbleString OPTIONAL,

surname

[ I] IMPLICIT PrintableStrin S,

BankAccount} ;

BankAccount : : =

NumericString ;

END

It is fairly easy to understand the meaning of this protocol. It gives the opportunity to send two kinds of message :

* Raise the credit of a client with a certain amount of money

• Lower the credit of a client with a certain amount of money

5.3.2. Protocol implementation

Rather than discussing the generated internal representation in detail, we will provide an implementation in PASCAL on how to make use of it.

First we define some constants to make your program easy to understand. Their values can be obtained directly from the illustration of the internal representation in the information file.

CONST

ChristianName = I;

(* StringNr of ChristianName ~ I *)

SurName = 2 ;

(* StringNr of SurName = 2 *)

B a n k A c c o u n t = 3 ;

( * S t r i n g N r o f B a n k A c c o u n t = 3 *)

Amount = 1 ;

(* IntegerNr of Amount = 1 *)

KindOfOrder = 1 ;

(* ChoiceNr of Order = 1 *)

RaiseCredit = I;

(* RaiseCredit is the first alternative *)

LowerCredit = 2 ;

(* LowerCredit is the second alternative *)

Suppose the application just has to reflect an incoming message on the screen in a user-friendly form. If the machine receives an incoming bytestream the following actions will take place:

IF ValidX4OgByteStream( ByteStream,

Init ialBANKSt ruct ure)

THEN BEGIN

I F H a n k _ C h o i c e [ K i n d O f O r d e r ] . V a l u e = R a i s e C r e d i t

THEN

WriteLn( 'Raise the Credit of Client: ') ELSE

WriteLn( 'Lower t h e Credit of Client: ');

IF Bank_Str[ ChristianName] .FilledIn

(* This has to be checked because

the ChristianName is optional *) THEN BEGIN

WriteLn( 'Christian Name: ');

P.M.J. Hellemans, H.J.M. Decuypere / Automatic Protocol Generation Based on X.409 Specifications 117

WriteData( Bank_Str[ ChristianName].Value)

END ; WriteLn( 'Surname: '); WriteData( Bank_Str[ SurName].Velue); WriteLn( 'Bankaccount: '); WriteDate( Bank_Str[ BankAccount].Value); WriteLn( 'Amount: ', Eank_Int[ Amount].Value)

END ELSE

WriteLn( 'Invalid message received.');

Suppose that the application also foresees procedures with a user friendly declaration to construct the RaiseCredit and LowerCredit messages. Construc- tOrder could be defined and implemented as follows.

PROCEDURE Cons t ruc tOrde r ( EindOfOrd : INTEGER; ChrisN, SurN, BankA : String; Am : INTEGER; VAR ByteStream : Date);

BEGIN Bank_Choice[ KindOfOrder] .Filledln := TRUE; Bank_Choice[ KindOf0rder].Value := EindOfOrd;

Bank_Str[ DhrietianName].Filledln := TRUE; Bank_Str[ ChristianName].Value.LI :=

Length( ChrisN); Bank_Str[ ChrietianName].Value.Address :=

ADDRESS( ChrisN);

Bank_Str[ SurName].Filledln := TRUE; Bank_Str[ SurName].Value.LI :=

Length( SurN); Bank_Str[ SurName].Value.Address :=

ADDRESS( SurN);

Bank_Str[ BankAccount].Filledln := TRUE; Bank_Str[ BankAccount].Value.LI :=

Length( BankA); Bank_Str[ BankAccount] .Value .Address :=

ADDRESS( BankA);

Bank_Int[ Amount].FilledIn := TRUE; Bank Int[ Amount].Value := Am;

IF ConstructX4OgByteStream( ByteStream, InitialBANKStructure)

THEN (* message constructed correctly *)

ELSE WriteLn( 'ERROR In ConstructRaiseCredit.')

END (* ConstructOrder *) ;

If one wants to raise Tony Parker's credit with 1000 units, he just has to issue the following procedure call.

ConstructOrder( RaieeCredit, 'Tony', 'Parker', '789 5430288 17', 1O00, Message);

It is clear from this example that the implementation of a protocol becomes more flexible and much easier to write and to understand. The implementor doesn't even have to know anything about the exact encoding of the protocol data units.

6. FUTURE DIRECTIONS

The further familiarisation with the OSI layered architecture and the still increasing demand for new services result in an increased interest in methodolo- gies which permit the flexible speflcication, verifica- tion and implementation of new protocols, x .409 is a good basis for such methodology.

Remote operations, which are defined by using X.409 MACROs, present a concept of increasing importance in the context of distributed applications. They provide a standard way to invoke operations in an execu- tion environment present in another computer. ECMA even states that "This methodology is likely to be a key factor in the overall success of OSI standardisa- tion" [6,7].

6.1. X.200 series of recommendations

The fact that the scope of x . 4 0 9 is not limited to the MHS is confirmed by the fact that it will become the subject of an independent recommendation in the 1988 version of the X.200 series. This change puts x . 4 0 9 in a more general context and will probably result in a widerspread use of it.

6.2. Value Added Services and Networks

Value Added Services (VASs) are services provided to communication system subscribers on top of the pure telecommunication oriented services. Such VASs to a large extent act upon the data transmitted within a communication whereas communication oriented services primarily act upon the control part of it. Value Added Networks (VANs) are special purpose networks built-up to provide a number of VASs to their subscribers.

The success of both VASs and VANs completely depend on the accessibility of these services, which can directly be translated in the availability of standardised specifications for them. It is likely that in the future applications in the highest layer of the osI model like MAIL, DIRECTORY, FTAM, . . . ) will b e specif ied

in X.409 or ASN. I[5].

118 P.M.J. Hellemans, H.J.M. Decuypere /Automatic Protocol Generation Based on X.409 Specifications

6.3. Network Management

Along with the increased interest in communication and especially in communication services came the quest for higher communication quality and availability. Therefore, the network management aspects have become a key item in recent developments.

The messages that are to be exchanged in the course of managing a network are not yet well defined. x .409 provides the designer with a flexible way of defining those messages, x . 409 is therefore rapidly gaining interest in the area of network management. The automated implementation of application protocols significantly shortens the turn-around time dur- ing successive protocol definitions.

The TCAP recommendations - which present a mech- anism to support network management functions - also make use of x . 409 specifications [10].

6.4. Intelligent Networks

A new topic in the area of telecommunication is the notion of intelligent networks which aim at a flexible way to introduce new services in the communication network both by the equipment manufacturer, the network provider and the end-user. This will cre- ate an open market for services.

As in any open market situation, the success of a service and/or a service provider will depend on the abil- ity to efficiently adapt to the needs and requests of the subscriber community. This flexibility must be based on a standardised way of specifying protocols and services and a flexible and automated way to implement them rapidly.

7. CONCLUSIONS

The X. 409 recommendation presents a Standard No- tation to specify protocol data units and a Standard Representation to encode them.

The machine processable form of the Standard Nota- tion and the general computer language orientation of the concepts have important implications. They open possibilities of software tools being able to generate executable code for the protocol and link this to the user's application code. This promises greatly simpli- fied design, development, testing and maintenance of distributed applications.

The availability of tools that support full X.409 therefore will likely be a key element in future projects in the area of telecommunication. The importance of such tools will augment due to the increased demand for new services.

The tools developed at Bell Telephone Mfg Co Re- search Centre so far are not complete but form a sound basis for a more elaborate protocol development environment which will permit to implement new protocols in a rapid and flexible way. The tools enabled us to implement an MHS prototype in less than 2 man-year, design and implementation of the tools themselves inclusive.

REFERENCES

[1] Reference model of Open Systems Interconnee- tion for CCITT applications, Rec. x.200, in: Data communication networks: Open Systems Interconnection (OSI), system description techniques, Volume VIII, Fascicle VIII.5 (1985).

[2] Session protocol specification for Open Systems Interconnection for CCITT applications, Rec. X.225, in: Data communication networks: Open Systems Interconnection (OSI), system description techniques, Volume VIII, Fascicle VIII.5 (1985).

[3] Message handling systems : presentation trans- fer syntax and notation, Rec. X.409, in: Data communication networks: message handling systems, Volume VIII, Fascicle VIII.7 (1985).

[4] Chadwick, D., FTAM: the development of a com- mercial product, in: Proceedings of the Interna- tional Conference on Open Systems (Online Pub- lications, Pinner, UK, 1987).

[5] OSI Directory Access Service and Protocol, ECMA TR/32 (1985).

[6] Remote Operations: Concepts, Notation and Connection-Oriented Mappings, ECMA TC32- TG4/85/45 (1985).

[7] Distributed Services Framework, ECMA TC32- TG5/86/51 (1986).

[8] Jensen, K. and Wirth, N., PASCAL user manual and report (Springer Verlag, New York, 1978).

P.M.J. Hellemans, H.J.M. Decuypere / Automatic Protocol Generation Based on X.409 Specifications 119

[9] Lewi, J., De Vlaminck, K., Huens, J. and Steeg- mans, E., A Programming Methodology in Com- piler Construction (North Holland Publishing Company, Amsterdam, 1982)

[10] TCAP Formats and Encoding, CCITT Working Party XI/2, Draft Rec. Q.773 (1987).

[11] Aho, A. and Ullman, J., Principles of Compiler Design (Addison-Wesley, Reading, Massaehus- sets, 1977).

[12] Myer, T., The MHS Recommendations, Struc- ture and Implementation Perspective, in: Sci- ence, Systems and Services for Communications (1984) pp. 115-120.

Documents

Automatic protocol generation based on x.409 specifications