Formal Specication of the X.

400 Reliable Transfer Service

Michael J. Butler
Programming Research Group
Oxford University Computing Laboratory
8{11 Keble Road
Oxford
OX1 3QD
Broadcom E ireann Research Ltd.
Kestrel House
Clanwilliam Place
Dublin 2.
June 1990

1 Introduction
X.400 [CCI85] is a CCITT/ISO standard for a message handling system designed to
sit at the application layer of the open system reference model. The system provides
special facilities such as deferred delivery, multiple destination and conversion of data
formats. The reliable transfer service (RTS) is in eect a mini-layer between X.400 and
the underlying layers. The entities above the RTS (the RTS-Users) provide the special
facilities but in this document we are only concerned with the RTS itself.
[But89] models the RTS as two protocol entities (RTS-Servers) co-operating via the
OSI Session layer (see gure 1). A simplied model of the Session layer was assumed
and both RTS servers were modelled as CSP [Hoa85] processes. This structure re ects
the style of the CCITT X.400 recommendations and the OSI architecture on which the
service is implemented. However, as is pointed out in the conclusion of [But89], this
style of specication does not give a clear description of the end-to-end service provided
to the RTS-Users by a set of RTS-Servers co-operating via the Session layer. In order to
see this we need a thorough understanding of the Session layer, and we need to analyse
the eect of such co-operation. The intended eect was that an RTS-User would be
provided with the facility to open an association with another RTS-User and then be
provided with the facility for the reliable transfer of information back and forth between
both RTS-Users.
In this paper we abstract away from the structure of gure 1 and also generalize the
model to include any number of RTS-Users. The set of RTS-Servers and the Session

1
 RTS-User RTS-User
6 6
? ?
RTS-Server RTS-Server
6 6
? ?
Session Layer

Figure 1: Session Layer and RTS Servers

layer will be combined into a single agent called the RTS (see gure 2). The RTS will
provide a service to all RTS-Users, namely, the facility to open an association with a
peer RTS-User and then to transfer information reliably. The structure of gure 1 can
then be regarded as a decomposition of the RTS (except of course that we require n
RTS-Servers rather than 2) and such a decomposition would be a stage in the design
process. Architecturally, gure 2 represents the most abstract form that the specication
can take.
In formally specifying the RTS of gure 2 an object-oriented style will be taken.
A formal model in Z [Spi89] of an object called Association will be given. This will
represent a single association between two distinct RTS-Users. It will consist of a state-
space and some operations on that state-space. In specifying the association operations
a constraint-based approach will be taken. A basic state-change for each operation will
be given. Each operation will be further constrained using a set of operation invariants.
These constraints will be used to decree the conditions under which certain state-changes
are permitted. This style allows us to specify dierent constraints separately and no more
than the schema calculus of Z is required in order to combine them.
The RTS will then be specied as a system which manages many such Association
objects. It will be modelled as a CSP process that interacts synchronously with its
environment (the set of RTS-Users). At this stage we will add the constraint that an
association can only exist between two RTS-Users that are linked. This represents the
physical constraints of the network on which the RTS is to be implemented.
A distinction will be made between normal RTS operations (service operations) such
as opening an association or transferring information and RTS management operations
such as creating a new link. The formal specication will allow this distinction to be
very clear. The bulk of this paper is concerned with service operations since the CCITT
recommendations are not at all concerned with management issues.

2
 RTS-User1 RTS-User2 RTS-Usern
6 6 6
? ? ?
RTS

Figure 2: Abstract Architecture of RTS

The RTS will be specied as a large CSP process. A state-based approach to CSP will
be used. Section 2 gives a state-based specication of the Association object. Section
3 uses this to give a state-based specication of the RTS and discusses how this is then
viewed as the specication of a CSP process. Finally some other unsolved issues are
discussed.

2 Association Object
As already mentioned, the formal object Association is intended to model a single as-
sociation between two distinct RTS-Users. In order to control an association the RTS
must provide both RTS-Users with, in CCITT parlance, a set of service elements (for
example the OPEN service element or the TRANSFER service element). Each service
element has either four or two service primitives (respectively conrmed/unconrmed
service element). With a conrmed service, one RTS-User issues a request resulting in
the peer RTS-User receiving an indication. That peer RTS-User then issues a response
resulting in the original RTS-User receiving a conrmation. An unconrmed service
element only has a request and an indication.
In the formal model the state-space of an Association consists of two buered chan-
nels (see gure 3). Here the initiator is the RTS-User that issues the OPEN request and
the responder is the peer RTS-User. Both channels carry service tokens between the two
RTS-Users. These channels are logical channels and are intended to model the services
oered by the lower layers of OSI. A request primitive corresponds to writing a request
service token to one end of a channel, and an indication corresponds to reading that
token from the other end of the channel. There is a similar correspondence between re-
sponses/conrmations and writes/reads of response service tokens. Later we will see that
rather than writing and reading values to and from the channels directly, the initiator
and responder interact synchronously with the RTS (CSP interaction). Such interaction
will result in RTS state-changes i.e. writes/reads of channels.

3
 Association
- Forward Channel -
Initiator Side Responder Side
 Reverse Channel 

Figure 3: Association Logical Channels

The state-space of the association object is given in section 2.1. Each service prim-
itive is provided by an operation on this state-space. For example, the OPEN request
primitive is dened by the following operation (conventions used are described later):
OpenRequest
AssociationOperation
fwd h+iopen req

The full list of association operations is given in the appendix. In 2.2 extra constraints
on these operations will be dened using operation invariants. The precise eect of such
constraints will be examined in 2.3.
2.1 Association State-Space
Firstly, the required set of service tokens are specied using a Z free type denition:
ST ::= open req j open resp (Reply )
j transfer (APDU )
j turn please
j turn give
j close req j close resp
Some tokens carry parameters. For example, open resp can carry parameters of type
Reply . A responder can decide to accept or reject an open request by the initiator. The
responders answer is carried in the open resp token so we dene Reply as:
Reply ::= accepted j rejected
A transfer token carries the actual data to be transferred. The type of this parameter
is APDU (Application Protocol Data Unit) which is assumed as a given type:
[APDU ]
To simplify the specication process a history variable is introduced. This records
all writes/reads to the logical channels in the order in which they happen. The history
4
variable is dened as a sequence of history tokens, where history tokens are dened as:
HT ::= write fwd (ST )
j read fwd (ST )
j write rtn (ST )
j read rtn (ST )
The Association state schema has three variables: the forward and return logical
channels (both modelled as sequences) and the history variable:
Association
fwd ; rtn : seq ST
hist : seq HT
The initial value for an association object has empty channels and the null history:
InitialAssociation
Association
fwd = rtn = hi
hist = hi
An unconstrained state-change is dened as:

Association
Association
Association 0

2.2 Operation Invariants

The lifetime of an association is divided up into three main phases: the opening phase,
the exchange phase and, the closing phase. The invariants in this subsection are divided
accordingly. These invariants will only constrain operations which write to a logical
channel. They will decree under what conditions, as dened by the protocol, such
operations can take place. Operations which read from a logical channel will be allowed
provided the appropriate token is at the head of the channel.
Firstly, some channel invariants are specied which will constrain the type of opera-
tions that can be performed on the logical channels and their relationship to the history
variable.
Channel Invariants
The following notation will be used for the purposes of this specication to describe
respectively writes/reads of value x to/from channel c :
c h+ix =b (c = c a hx i)
0

c h?ix =b (c = hx i a c )
0

5
These dene relations between the before state and the after state and are intended to
make the specication easier to read. For transitions which leave a channel unchanged
we use:
c =b (c = c )
0

All the invariants given in this section constrain all operations on Association . Op-
eration invariants have names suxed with \OpInv ". The rst two operation invariants
constrain the type of operations that can be performed on the channels to either writing,
reading or leaving the channel unchanged:
ChannelOpInv 0

Association
9 st : ST 
fwd h+ist _ fwd h?ist _ fwd

A similar constraint applies to rtn :

ChannelOpInv 1 =b ChannelOpInv 0[rtn =fwd ]
The disjuncts of ChannelOpInv 0 are mutually exclusive so that one and only one of the
three operations is performed on fwd . Similarly for rtn in ChannelOpInv 1. The next
constraint decrees that at most one of the channels can be changed by an operation (at
least one channel must remain unchanged):
ChannelOpInv 2

Association
fwd _ rtn

ChannelOpInv =b ChannelOpInv 0 ^ ChannelOpInv 1 ^ ChannelOpInv 2

From ChannelOpInv we can deduce that each operation on Association will involve
either a write or a read to one of two channels or else leave both channels unchanged.
It is required that whenever a channel is operated on, the history variable must be
updated accordingly:
UpdateHistoryOpInv

Association
8 st : ST 
fwd h+ist ) hist = hist a hwrite fwd (st )i
0

fwd h?ist ) hist = hist a hread fwd (st )i

0

rtn h+ist ) hist = hist a hwrite rtn (st )i

0

rtn h?ist ) hist = hist a hread rtn (st )i

0

6
For the moment we say nothing about what should happen to the history variable during
an operation which leaves both channels unchanged. Later an operation will be dened
which resets the history variable to the null trace once an association has been closed.
This operation will leave both channels unchanged.
Notice there is some redundancy in the Association state-space since we ought to
be able to dene both fwd and rtn as functions of the history variable. Dening one
state component in terms of another state component means that we don't have to worry
about consistency between them since we get it for free. However, modelling fwd and rtn
as channels in there own right results in a more intuitively understandable specication.
Consistency between the history variable and the channels is maintained by the above
operation invariant.
Opening Phase
Opening of an association is started by the initiator issuing an open request. This means
an open req is written to the fwd channel which can only happen when the association
is in the closed state. The closed state is dened simply as:
IsClosed
Association
hist = hi

The following operation invariant decrees that an open req can only be written to fwd
when the association is closed:
OpeningOpInv 0

Association
IsClosed ( fwd h+iopen req

A more \literal" interpretation of this constraint on the initiator would be: if the rela-
tionship fwd = fwd a hopen req i holds between the before and after states, then the
0

condition IsClosed must hold of the before state.

The responder can only issue an open response if it has already read an open req
token from the fwd channel and has not yet issued an open response:
WaitingOpenResponse
Association
read fwd (open req ) 2 ran hist
8 r : Reply 
write rtn (open resp (r )) 62 ran hist

7
 OpeningOpInv 1

Association
8 r : Reply 
WaitingOpenResponse ( rtn h+iopen resp (r )

OpeningOpInv =b OpeningOpInv 0 ^ OpeningOpInv 1

Exchange Phase
An association is dened as being open when an open resp with reply value accepted
has been read from the return channel and no close request has yet been issued by the
initiator. Exchange of messages can now take place.
IsOpen
Association
read rtn (open resp (accepted )) 2 ran hist
write fwd (close req ) 62 ran hist

During the exchange phase, the transfer of messages is only ever in one direction.
There is a concept called the \turn" and only the agent holding the turn can issue a
message transfer request. The turn-holder can relinquish its possession of the turn by
issuing a turn-give request. Initially the initiator holds the turn. So, the initiator holds
the turn if no turn-give requests have been issued, or if the most recent turn-give event
was a reading of a turn give token from the return channel:
turn give events : PHT
turn give events = f write fwd (turn give ); read fwd (turn give );
write rtn (turn give ); read rtn (turn give ) g

InitiatorHoldsTurn
Association
(hist  turn give events ) = hi
_
last (hist  turn give events ) = read rtn (turn give )

This constraint can be read simply as:

 There have been no turn-give events, Or
 The last turn-give event was a reading of a turn-give token from the return channel.

8
 The responder holds the turn whenever the last turn-give event was a reading of a
turn give token from the forward channel:
ResponderHoldsTurn
Association
(hist  turn give events ) 6= hi
last (hist  turn give events ) = read fwd (turn give )
Here, t  s restricts the trace t to those elements in set s .
The next operation invariant constrains the issuing of message transfer requests. The
initiator can only issue a transfer request when the association is open and it holds the
turn. Similarly for the responder:
TransferOpInv

Association
8 a : APDU 
IsOpen ^ InitiatorHoldsTurn ( fwd h+itransfer (a )
IsOpen ^ ResponderHoldsTurn ( rtn h+itransfer (a )
A similar operation invariant constrains the issuing of turn-give requests:
TurnGiveOpInv

Association
IsOpen ^ InitiatorHoldsTurn ( fwd h+iturn give
IsOpen ^ ResponderHoldsTurn ( rtn h+iturn give
An RTS-User not holding the turn can request its peer to relinquish the turn by
issuing a turn-please request. Neither the turn-give or the turn-please are conrmed
service elements. So a turn-holder is not obliged to issue a turn-give after receiving a
turn-please indication. In fact a turn-holder can relinquish the turn without ever having
received a turn-please indication. An RTS-User can issue a turn-please request whenever
the association is open and it does not hold the turn:
TurnPleaseOpInv

Association
IsOpen ^ : InitiatorHoldsTurn ( fwd h+iturn please
IsOpen ^ : ResponderHoldsTurn ( rtn h+iturn please
Note that although (InitiatorHoldsTurn ^ ResponderHoldsTurn ) can never be true, the
condition (: InitiatorHoldsTurn ^ : ResponderHoldsTurn ) is logically equivalent to:
(hist  turn give events ) 6= hi ^
( last (hist  turn give events ) = write fwd (turn give ) _
last (hist  turn give events ) = write rtn (turn give ) )

9
This means that neither RTS-User holds the turn when there is a turn give token in
transit in one of the channels.
Closing Phase
An association can only be closed by the initiating RTS-User, and only when that agent
holds the turn. The closing phase is started by the initiator issuing a close request:
ClosingOpInv 0

Association
IsOpen ^ InitiatorHoldsTurn ( fwd h+iclose req
The responder can only issue a close response if it has already read a close req token
from the fwd channel and has not yet issued a close response:
WaitingCloseResponse
Association
read fwd (close req ) 2 ran hist
write rtn (close resp ) 62 ran hist

ClosingOpInv 1

Association
WaitingCloseResponse ( rtn h+iclose resp

ClosingOpInv =b ClosingOpInv 0 ^ ClosingOpInv 1

2.3 Association Operations
All the invariants can now be brought together using schema inclusion. A constrained
class of association operation is obtained by including all the operation invariants in the
schema AssociationOperation . All service primitive operations use AssociationOperation
in their declaration so they will be constrained by all the invariants:
AssociationOperation

Association
ChannelOpInv
UpdateHistoryOpInv
OpeningOpInv
TransferOpInv
TurnGiveOpInv
TurnPleaseOpInv
ClosingOpInv

10
 We now examine the logical eect of the constraints on operations. Consider the
denition of OpenRequest :
OpenRequest
AssociationOperation
fwd h+iopen req
Using the rules of the schema calculus we can show that this is equivalent to the following
schema:
OpenRequest

Association
fwd h+iopen req
ChannelOpInv
UpdateHistoryOpInv
OpeningOpInv
Those invariants not relevant to OpenRequest have been omitted as they are trivially
satised. Continuing with the predicate part we get the equivalence:
, fwd h+iopen req
rtn
8 st : ST  fwd h+ist ) hist = hist a hwrite fwd (st )i
0

IsClosed ( fwd h+iopen req

, fwd h+iopen req
rtn
hist = hist a hwrite fwd (open req )i
0

IsClosed
From this we can calculate the pre-condition of OpenRequest to be:
pre OpenRequest
Association
IsClosed
This denes the conditions under which the OpenRequest operation can happen.
By similar reasoning OpenIndication is equivalent to:
OpenIndication

Association
fwd h?iopen req
rtn
hist = hist a hread fwd (open req )i
0

11
The pre-condition for this operation is simply:
pre OpenIndication
Association
9 fwd : seq ST 
0

fwd = hopen req i a fwd 0

The predicate part is equivalent to:

fwd 6= hi ^ head (fwd ) = open req
Again, by similar reasoning, the pre-condition for InitiatorTransferRequest is calcu-
lated to be:
pre InitiatorTransferRequest
Association
a ? : APDU
IsOpen ^ InitiatorHoldsTurn
Rather than separating the constraints into invariants we could have written each
operation out in full with the constraints being implicitly satised, since it has just been
shown that both styles are logically equivalent. However, the style we have chosen is
closer to the style of a requirements document and so we can be more condent that the
specication does correctly model those requirements.
Association Reset
We want the possibility of reusing an association when it is nished. An association is
nished if the following condition holds:
IsFinished
Association
last (hist ) = read rtn (close resp )
_
last (hist ) = read rtn (open resp (rejected ))
The following operation resets the history variable to the null trace. When the RTS is
regarded as a CSP process we can internalise this operation:
ResetAssociation
AssociationOperation
IsFinished
hist = hi
0

fwd
rtn

12
We can prove that the following condition on the state is invariant (i.e. always satised):
IsFinished ) fwd = rtn = hi
This means that after the reset operation the association state will satisfy InitialAssociation .

3 RTS
The denition of the Association is now used in the specication of the RTS. Firstly,
the RTS state-space is specied, then the set of operations is given. The operations are
divided up into service operations and management operations. It is then shown how
these can be viewed as the specication of a CSP process.
3.1 RTS State-Space
Each RTS-User needs to be uniquely referenced. Also, since multiple associations be-
tween any two RTS-Users must be allowed, we need to identify associations uniquely
with an extra identier. The following types are introduced:
[RTS User ; Ident ]
A reference to a particular association has three components: the initiator, the responder,
and a unique identier:
AssocRef == RTS User  RTS User  Ident
The RTS must support associations between any two RTS-Users that are linked. The
RTS state has two components: a function mapping association references to association
objects, and a relation linked . Assume that u , v and i are universally quantied in the
following schema:
RTS
assocs : AssocRef ! 7 7 Association
linked : RTS User $ RTS User
: linked (u ; u )
(u ; v ; i ) 2 dom assocs ) linked (u ; v )
linked (u ; v ) ) 9 i : Ident  (u ; v ; i ) 2 dom assocs

The three predicates state respectively:

 linked RTS-Users must be distinct,
 associations can only exist between RTS-Users that are linked,
 if two RTS-Users are linked then it must be possible to have at least one association
between them.
13
 Note that linked has not been dened as a symmetric relation. So if linked (u ; v )
but : linked (v ; u ) then u can initiate an association with v but v cannot initiate an
association with u .
The initial state of the RTS is simply:
InitialRTS
RTS
assocs = fg
linked = fg

3.2 Service Operations

In a service operation both the relation linked and the domain of the assocs function
remain unchanged. Also, each service operation can only refer to a single association
object which must exist in assocs and all other association objects are unaected:
ServiceOperation

RTS
(u ; v ; i ) : AssocRef
linked = linked
0

dom assocs = dom assocs

0

(u ; v ; i ) 2 dom assocs
f(u ; v ; i )g C? assocs = f(u ; v ; i )g?
0
C assocs

Here, s ? C f removes all elements in s from the domain of f .

The technique of schema promotion is used to convert an association operation into
a service operation. The schema ServiceOperationPromote matches the before and after
values referred to by an association operation with the before and after values referenced
by (u ; v ; i ) in the RTS:
ServiceOperationPromote
ServiceOperation
AssociationOperation
Association = assocs (u ; v ; i )
assocs = assocs  f(u ; v ; i ) 7! Association g
0 0

Here, f  g is the result of overriding function f with function g .

The operation OpenRequest on a single association can be promoted to an RTS-level
service operation as follows:
OpenRequestRTS =b
(OpenRequest ^ ServiceOperationPromote ) n AssociationOperation
14
Although the variables of AssociationOperation are hidden in the denition of the
OpenRequestRTS operation, this should not be regarded as information hiding in the
object-oriented sense. The association referenced by (u ; v ; i ) still exists in the range of
the assocs function which is certainly visible since, by the rules of the schema calculus,
the signature of OpenRequestRTS is the same as the signature of ServiceOperation .
Parameters to association operations such as the APDU in a transfer request also
remain visible. Consider the following denition:
InitiatorTransferRequestRTS =b
(InitiatorTransferRequest ^ ServiceOperationPromote ) n AssociationOperation
This schema has the following signature:
ServiceOperation
a ? : APDU
All the association operations listed in the appendix can be promoted in the same way,
as can the association reset operation.
3.3 Management Operations
Management operations are provided to the administrators of the RTS rather than the
RTS-Users. We will not specify a detailed list of management operations. The point
is to illustrate how management operations can be formally distinguished from normal
service operations. Such distinction prevents potential confusion for the readers of the
specication.
Two management operations are dened. The rst is for creating a link between
two non-linked RTS-Users, while the second is for breaking such a link. A management
operation can refer to more then one association so it is not as constrained as a service
operation:
ManagementOperation

RTS
CreateLink sets up a link between RTS-Users u and v . This will allow some set of
associations to exist between u and v . This is achieved by adding a nite number of
initial-valued association objects to the assocs function:
CreateLink
ManagementOperation
u ; v : RTS User
u 6= v
: linked (u ; v )
linked = linked [ f(u ; v )g
0

9 I : PIdent 
assocs = assocs [ f(u ; v ; i ) 7! InitialAssociation j i 2 I g
0

15
Note the asymmetry in this operation. The links set up only allow u to initiate associa-
tions with v but not vice versa. To achieve a two-way link we could dene the following
operation:
CreateDoubleLink =b CreateLink o9 (CreateLink [v =u ; u =v ])
BreakLink removes all association objects between u and v from the RTS. Again
there is an asymmetry between u and v :
BreakLink
ManagementOperation
u ; v : RTS User
linked (u ; v )
linked = linked n f(u ; v )g
0

assocs = f(u ; v ; i ) j i 2 Ident g C

0
? assocs

4 Other Issues
4.1 Renement and Decomposition
Renement is the major part of the design process though it is given little space here.
The renement we need is CSP renement based on the notion of simulation. A process
C is a renement of a process A if C exhibits the same observable behaviour as A.
In fact C doesn't have exactly the same observable behaviour as A since we allow for
resolution of any non-determinism in A. But an important point is that C can have
a dierent state structure to A | one that is more concrete and easier to implement.
Another important point is that we can introduce internal events so that we rene down
to a more detailed architecture which re ects the distributed nature of a communications
network.
Woodcock and Morgan [WM90] dene the notion of forward simulation. This is a
relation between the state-structure of A and the state-structure of C and if it satises
certain conditions then C is said to rene A. Taking the Association object, we can
dene a renement of its state structure as follows:
AssocState ::= closed j opening j open j closing
TurnHolder ::= initiator j responder j neither

ConcreteAssociation
fwd ; rtn : seq ST
ast : AssocState
turn : TurnHolder

Here the history variable has been replaced by ast and turn . A forward simulation
between Association and ConcreteAssociation can be dened such that when viewed as
16
CSP processes they both exhibit the same behaviour (allowing for resolution of non-
determinism).
The RTS will need to be decomposed into a number of sub-processes in order for
it to be implemented on a network of communicating nodes. For example, a rst step
could be to decompose it into a Session Layer and n RTS-Servers (see gures 1 and 2).
If the communications between the subprocesses are hidden and the correct renement
rules are followed then the combination will exhibit the same observable behaviour as
the abstract RTS, remembering that the observable behaviour occurs at the interaction
points between the RTS and the RTS-Users.
4.2 Constraint-Based Specication
The style of specication used to dene the Association object was rstly to dene a
basic set of operations and then to constrain these operations with a set of operations
invariants. The reason for using this style was so that dierent concerns and constraints
could be specied separately and so make the specication easier to read and understand.
The usual approach when specifying a system in Z is to give a state-space, an initialisa-
tion and a set of operations and then to prove that the system satises certain constraints
(safety properties). In this way the constraints are implicit in the specication.
Another approach is to start explicitly with the set of constraints and regard this as
the specication of the system. From this an initialisation and a set of operations can
be derived. Unity [CM88] takes such an approach. Constraints are specied in Unity
logic which are conditions on an implicit Unity program. An example of a statement in
Unity logic is
p unless q
Here p and q are conditions on the state and \p unless q " means that p must remain
true at least as long as q is not satised. This is dened in terms of a condition on the
actions of the implicit Unity program:
p ^ : q ) wp (act ; p _ q ); for all act in program.
Unity has an associated set of theorems which allows us to prove more properties
given a basic set of properties. Also, renement can be performed at the property level
rather than rening each individual action. A problem with Unity when it comes to
specifying communications systems though is that it only really deals with the notion of
state and not with the notion of observable events.
The approach taken in this document lies somewhere between the two approaches
just mentioned. What are needed are some theorems which would allow us to prove
certain properties (e.g. state invariants, operation invariants) given other properties
rather than having to reason about them using the denitions of the actions. It would
also be useful to be able to reason about renements at the property level rather than
at the individual action level.
However, unlike in Unity where a purely constraint-based approach is taken, it will
still be necessary to give a set of basic state-changes corresponding to the observable
17
events of the system. These could be further constrained in a manner similar to that
demonstrated in this document.

5 Conclusions
An abstract specication in Z of the X.400 RTS has been presented. An object ori-
ented style was used, where association objects where rst specied, and then the RTS
was specied such that it manipulated these objects. The specication is clear and
unambiguous, and independent of implementation details.

References
[But89] M.J. Butler. Formal techniques applied to the X.400 Reliable Transfer Service.
M.Sc. thesis, Programming Research Group, University of Oxford, 1989.
[CCI85] CCITT. Message handling systems. Recommendations X.400 - X.430. Red
Book VIII.7, CCITT, Geneva, 1985.
[CM88] K. Mani Chandy and J. Misra. Parallel Program Design { A Foundation.
Addison{Wesley, 1988.
[Hoa85] C.A.R. Hoare. Communicating Sequential Processes. Prentice{Hall, 1985.
[Spi89] J.M. Spivey. The Z Notation - A Reference Manual. Prentice{Hall, 1989.
[WM90] J.C.P. Woodcock and C.C. Morgan. Renement of state-based concurrent sys-
tems. In Proceedings VDM '90, Kiel, April 1990.

A. Appendix
Association Operations
A.1 OPEN Service Element
OpenRequest
AssociationOperation
fwd h+iopen req

OpenIndication
AssociationOperation
fwd h?iopen req

18
 OpenResponse
AssociationOperation
r ? : Reply
rtn h+iopen resp (r ?)

OpenConrm
AssociationOperation
r ! : Reply
rtn h?iopen resp (r !)

A.2 TRANSFER Service Element

InitiatorTransferRequest
AssociationOperation
a ? : APDU
fwd h+itransfer (a ?)

ResponderTransferRequest
AssociationOperation
a ? : APDU
rtn h+itransfer (a ?)

InitiatorTransferIndication
AssociationOperation
a ! : APDU
rtn h?itransfer (a !)

ResponderTransferIndication
AssociationOperation
a ! : APDU
fwd h?itransfer (a !)

A.3 TURN-PLEASE Service Element

InitiatorTurnPleaseRequest
AssociationOperation
fwd h+iturn please

19
 ResponderTurnPleaseRequest
AssociationOperation
rtn h+iturn please

InitiatorTurnPleaseIndication
AssociationOperation
rtn h?iturn please

ResponderTurnPleaseIndication
AssociationOperation
fwd h?iturn please

A.4 TURN-GIVE Service Element

InitiatorTurnGiveRequest
AssociationOperation
fwd h+iturn give

ResponderTurnGiveRequest
AssociationOperation
rtn h+iturn give

InitiatorTurnGiveIndication
AssociationOperation
rtn h?iturn give

ResponderTurnGiveIndication
AssociationOperation
fwd h?iturn give

A.5 CLOSE Service Element

CloseRequest
AssociationOperation
fwd h+iclose req

20
CloseIndication
AssociationOperation
fwd h?iclose req

CloseResponse
AssociationOperation
rtn h+iclose resp

CloseConrm
AssociationOperation
rtn h?iclose resp

21