RFC 2204
ODETTE File Transfer Protocol
Network Working Group D. Nash Request for Comments: 2204 ODETTE Category: Informational September 1997 ODETTE File Transfer Protocol Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo describes a file transfer protocol to facilitate electronic data interchange between trading partners. The protocol, denoted the ODETTE File Transfer Protocol, supports both direct communication between installations and indirect communication via a third party clearing centre. It was developed by the Organisation for Data Exchange by Tele Transmission in Europe to facilitate communication within the European motor industry and is presented here to allow for wider use within the Internet community. Table of Contents 1. Introduction 3 1.1 - Background 3 1.2 - Relationship to the original ODETTE Standard 3 1.3 - General Principles 3 1.4 - Structure 4 1.5 - Virtual Files 4 1.6 - Service Description 7 2. Network Service (TCP Transport Service) 7 2.1 - Introduction 7 2.2 - Service Primitives 7 2.3 - Port Assignment 9 3. File Transfer Service 9 3.1 - Model 10 3.2 - Session Setup 11 3.3 - File Transfer 13 3.4 - Session Take Down 16 3.5 - Service State Automata 19
4. Protocol Specification 22 4.1 - Overview 22 4.2 - Start Session Phase 22 4.3 - Start File Phase 23 4.4 - Data Transfer Phase 26 4.5 - End File Phase 27 4.6 - End Session Phase 27 4.7 - Problem Handling 28 5. Commands and Formats 28 5.1 - Conventions 28 5.2 - Commands 29 5.3 - Command Formats 29 5.4 - Identification Code 45 6. ODETTE-FTP Data Exchange Buffer 46 6.1 - Overview 46 6.2 - Data Exchange Buffer Format 46 6.3 - Buffer Filling Rules 47 7. Stream Transmission Buffer (TCP only) 47 7.1 - Introduction 47 7.2 - Stream Transmission Header Format 49 8. Protocol State Machine 50 8.1 - ODETTE-FTP State Machine 50 8.2 - Error Handling 50 8.3 - States 51 8.4 - Input Events 53 8.5 - Output Events 54 8.6 - Local Variables 55 8.7 - Local Constants 55 8.8 - Session Connection State Table 56 8.9 - Error and Abort State Table 58 8.10 - Speaker State Table 1 59 8.11 - Speaker State Table 2 63 8.12 - Listener State Table 65 8.13 - Example 68 9. Security Considerations 68 Appendix A Virtual File Mapping Example 69 Appendix B ISO 646 Character Subset 72 Acknowledgements 73 References 73 ODETTE Address 74 Author's Address 74
1. Introduction 1.1 Background The ODETTE File Transfer Protocol (ODETTE-FTP) was defined in 1986 by working group four of the Organisation for Data Exchange by Tele Transmission in Europe (ODETTE) to address the electronic data interchange (EDI) requirements of the European automotive industry. It was designed in the spirit of the Open System Interconnection (OSI) model utilising the Network Service provided by the CCITT X25 recommendation. Over the last ten years ODETTE-FTP has been widely deployed on systems of all sizes from personal computers to large mainframes. As a result of the wide scale deployment of internet technology and the trend towards global business practices, ODETTE has decided to extend the scope of it's file transfer protocol to allow the use of TCP/IP and to make the protocol available to the Internet community. This memo describes the ODETTE-FTP protocol using the Transmission Control Protocol for it's network service. 1.2 Relationship to the original ODETTE Standard This memo is an interpretation of version 1.3 of the ODETTE File Transfer Protocol [OFTP]. In the event of any ambiguity between this document and the original ODETTE-FTP, the original shall take precedence. For ODETTE-FTP on TCP/IP the following sections have been added with respect to the original document. Section 2 - Network Service Section 7 - Stream Transmission Buffer Appendix A - Virtual File mapping example 1.3 General Principles The aim of the ODETTE-FTP is to facilitate the transmission of a file between one or more locations in a way that is independent of the data communication network, system hardware and software environment. In designing and specifying the protocol, the following factors were considered. 1. The possible differences of size and sophistication (file storage, small and large systems).
2. The necessity to work with existing systems (reduce changes to
existing products and allow easy implementation).
3. Systems of different ages.
4. Systems of different manufactures.
5. The potential for growth in sophistication (limit impact and avoid
changes at other locations).
1.4 Structure
ODETTE-FTP is modelled on the OSI reference model. It is designed to
use the Network Service provided by level 3 of the model and provide
a File Service to the users. Thus the protocol spans levels 4 to 7
of model.
The description of the ODETTE-FTP contained in this memo is closely
related to the original 'X.25' specification of the protocol and in
the spirit of the OSI model describes:
1. A File Service provided to a user monitor.
2. A protocol for the exchange of information between peer
ODETTE-FTP entities.
A major consideration in adapting the protocol to use the
Transmission Control Protocol (TCP) was the desire to make no changes
to the existing protocol by adding the functionality required to
allow implementors to support internet communication with only minor
changes to existing ODETTE-FTP engines. To this end an additional
header has been added to the start of each exchange buffer to allow
the TCP byte stream to be broken up into the discrete exchange
buffers expected by the ODETTE-FTP protocol.
1.5 Virtual Files
Information is always exchanged between ODETTE-FTP entities in a
standard representation called a Virtual File. This allows data
transfer without regard for the nature of the communicating systems.
The mapping of a file between a local and virtual representation will
vary from system to system and is not defined here.
o---------o
Site | Local |
A | File A |
o---------o
|
o----------------------- Mapping A ------------------------o
| | |
| o---------o |
| | Virtual | |
| | File | |
| o---------o |
| o------------------------------------------------o |
| | | |
| | ODETTE-FTP | |
| | | |
| o------------------------------------------------o |
| o---------o o---------o |
| | Virtual | | Virtual | |
| | File | | File | |
| o---------o o----+----o |
| | | |
o------ Mapping B ------------------------ Mapping C ------o
| |
o---------o o----+----o
| Local | Site Site | Local |
| File B | B C | File C |
o---------o o---------o
A Virtual File is described by a set of attributes identifying and
defining the data to be transferred. The main attributes are:
1.5.1 Organisation:
Sequential
Logical records are presented one after another. The ODETTE-FTP
must be aware of the record boundaries.
1.5.2 Identification
Dataset Name
Dataset name of the Virtual File being transfered, assigned by
bilateral agreement.
Time stamp (HHMMSS)
A file qualifier indicating the time the Virtual File was made
available for transmission.
Date stamp (YYMMDD)
A file qualifier indicating the date the Virtual File was made
available for transmission.
The Dataset Name, Date and Time attributes are assigned by a Virtual
File's Originator and are used to uniquely identify the file. They
must not be changed by intermediate locations.
The Date attribute represents the decade and year in a two digit
field. Since the ODETTE-FTP only uses this information to identify a
particular Virtual File it will continue to operate correctly in the
year 2000 and beyond.
The User Monitor may use the Virtual File Date attribute in local
processes involving date comparisons and calculations. Any such use
falls outside the scope of this protocol and year 2000 handling is a
local implementation issue.
1.5.3 Record Format
Four record formats are defined.
Fixed (F)
Each record in the file has the same length.
Variable (V)
The records in the file can have different lengths.
Unstructured (U)
The file contains a stream of data. No structure is defined.
Text File (T)
A Text File is defined as a sequence of ASCII characters,
containing no control characters except CR/LF which delimits
lines. A line will not have more than 2048 characters.
1.5.4 Restart ODETTE-FTP can negotiate the restart of an interrupted Virtual File transmission. Fixed and Variable format files are restarted on record boundaries. For Unstructured and Text files the restart position is expressed as a file offset in 1K (1024 octet) blocks. The restart position is always calculated relative to the Virtual File. 1.6 Service Description ODETTE-FTP provides a file transfer service to a user monitor and in turn uses the Internet transport layer stream service to communicate between peers. These services are specified in this memo using service primitives grouped into four classes as follows: Request (RQ) An entity asks the service to do some work. Indication (IND) A service informs an entity of an event. Response (RS) An entity responds to an event. Confirm (CF) A service informs an entity of the response. Services may be confirmed, using the request, indication, response and confirm primitives, or unconfirmed using just the request and indication primitives. 2. Network Service (TCP Transport Service) 2.1 Introduction ODETTE-FTP peer entities communicate with each other via the OSI Network Service or the Transmission Control Protocol Transport Service [TCP]. This is described by service primitives representing request, indication, response and confirmation actions. For the internet environment, the service primitives mentioned below for the Network Service have to be mapped to the respective Transport Service primitives. This section describes the network service primitives used by ODETTE-FTP and their relationship to the TCP interface. In practice the local transport service application programming interface will be used to access the TCP service. 2.2 Service Primitives All Network primitives can be directly mapped to the respective Transport primitives when using TCP.
2.2.1 Network Connection N_CON_RQ ------> N_CON_IND N_CON_CF <------ N_CON_RS This describes the setup of a connection. The requesting ODETTE-FTP peer uses the N_CON_RQ primitive to request an active OPEN of a connection to a peer ODETTE-FTP, the Responder, which has previously requested a passive OPEN. The Responder is notified of the incoming connection via N_CON_IND and accepts it with N_CON_RS. The requester is notified of the completion of it's OPEN request upon receipt of _CON_CF. Parameters Request Indication Response Confirmation --------------------------------------------------------------------- Dest addr ------> same same same 2.2.2 Network Data N_DATA_RQ ------> N_DATA_IND Data exchange is an unconfirmed service. The Requester passes data for transmission to the network service via the N_DATA_RQ primitive. The Responder is notified of the availability of data via N_DATA_IND. In practice the notification and receipt of data may be combined, such as by the return from a blocking read from the network socket. Parameters Request Indication --------------------------------------------------------------------- Data ------------------> same 2.2.3 Network Disconnection N_DISC_RQ ------> N_DISC_IND An ODETTE-FTP requests the termination of a connection with the N_DISC_RQ service primitive. It's peer is notified of the CLOSE by a N_DISC_IND event. It is recognised that each peer must issue a N_DISC_RQ primitive to complete the TCP symmetric close procedure.
2.2.4 Network Reset ------> N_RST_IND An ODETTE-FTP entity is notified of a network error by a N_RST_IND event. It should be noted that N_RST_IND would also be generated by a peer RESETTING the connection, but this is ignored here as N_RST_RQ is never sent to the Network Service by ODETTE-FTP. 2.3 Port Assignment A ODETTE-FTP requester will select a suitable local port. The responding ODETTE-FTP will listen for connections on Registered Port 3305, the service name is 'odette-ftp'. 3. File Transfer Service The File Transfer Service describes the services offered by an ODETTE-FTP Entity to it's User Monitor. The implementation of the service primitives is a local matter.
3.1 Model o-------------------o o-------------------o | | | | | USER MONITOR | | USER MONITOR | | | | | o-------------------o o-------------------o | A | A ...............|...|... FILE TRANSFER SERVICE ...|...|............... | | | | F_XXX_RQ/RS | | F_XXX_IND/CF F_XXX_RQ/RS | | F_XXX_IND/CF V | V | o-------------------o o-------------------o | |- - - - - - >| | | ODETTE-FTP Entity | E-Buffer | ODETTE-FTP Entity | | |< - - - - - -| | o-------------------o o-------------------o | A | A N_XXX_RQ/RS | | N_XXX_IND/CF N_XXX_RQ/RS | | N_XXX_IND/CF | | | | ...............|...|...... NETWORK SERVICE ......|...|............... V | V | o---------------------------------------------------------o | | | N E T W O R K | | | o---------------------------------------------------------o Key: E-Buffer - Exchange Buffer F_ - File Transfer Service Primitive N_ - Network Service Primitive
3.2 Session Setup 3.2.1 Session Connection Service | | F_CONNECT_RQ ---->|------------|----> F_CONNECT_IND | | F_CONNECT_CF <----|------------|<---- F_CONNECT_RS | | Parameters Request Indication Response Confirm --------------------------------------------------------------------- called-address -> same --- ---- calling-address-> same --- ---- ID1 ------------> same ID2 ------------> same PSW1------------> same PSW2 -----------> same mode1 ----------> mode2 ----------> mode3 ----------> same restart1 -------> same -----------> restart2 -------> same --------------------------------------------------------------------- Mode Specifies the file transfer capabilities of the entity sending or receiving a F_CONNECT primitive for the duration of the session. Value: Sender-Only The entity can only send files. Receiver-Only The entity can only receive files. Both The entity can both send and receive files. Negotiation: Sender-Only Not negotiable. Receiver-Only Not negotiable. Both Can be negotiated down to Sender-Only or Receiver-Only by the User Monitor or the ODETTE-FTP entity.
Request Indication Response Confirm
---------------------------------------------------------------------
Sender-only ----> Receiver-only --> Receiver-only --> Sender-only
Receiver-only --> Sender-only ----> Sender-only ----> Receiver-only
Both -----+-----> Both ----+------> Both -----------> Both
| or +------> Receiver-only --> Sender-only
| or +------> Sender-only ----> Receiver-only
|
or +-----> Receiver-only --> Receiver-only --> Sender-only
or +-----> Sender-only ----> Sender-only ----> Receiver-only
---------------------------------------------------------------------
Restart
Specifies the file transfer restart capabilities of the User
Monitor.
Value:
Negotiation:
Request Indication Response Confirm
---------------------------------------------------------------------
restart = Y ----> restart = Y --+-> restart = Y ----> restart = Y
or +-> restart = N ----> restart = N
restart = N ----> restart = N ----> restart = N ----> restart = N
---------------------------------------------------------------------
3.3 File Transfer 3.3.1 File Opening | | F_START_FILE_RQ ---->|------------|----> F_START_FILE_IND | | F_START_FILE_CF(+|-) <----|------------|<---- F_START_FILE_RS(+|-) | | Parameters: Request Ind. RS(+) CF(+) RS(-) CF(-) -------------------------------------------------------------------- file-name ----> same ---- ---- ---- ---- date-time ----> same ---- ---- ---- ---- destination---> same ---- ---- ---- ---- originator----> same ---- ---- ---- ---- rec-format----> same ---- ---- ---- ---- rec-size -----> same ---- ---- ---- ---- file-size-----> same ---- ---- ---- ---- restart-pos1--> same-> restart-pos2-> same ---- ---- ---- ---- ---- ---- cause ------> same ---- ---- ---- ---- retry-later-> same -------------------------------------------------------------------- Notes: 1. Retry-later has values "Y" or "N". 2. Cause is the reason for refusing the transfer (1,..,13,99). 3. Restart-pos1 not equal 0 is only valid if restart has been agreed during initial negotiation. 4. Restart-pos2 is less than or equal to restart-pos1. 3.3.2 Data Regime | | F_DATA_RQ ---->|------------|----> F_DATA_IND | | Notes: 1. The data format within a F_DATA primitive is locally defined. 2. The File Transfer service may have to provide a flow control mechanism to regulate the flow of F_DATA primitives.
3.3.3 File Closing | | F_CLOSE_FILE_RQ --->|------------|----> F_CLOSE_FILE_IND | | F_CLOSE_FILE_CF(+|-) <---|------------|<---- F_CLOSE_FILE_RS(+|-) | | Parameters Request Ind RS(+) CF(+) RS(-) CF(-) --------------------------------------------------------------------- rec-count ---> same ---- ---- ---- ---- unit-count --> same ---- ---- ---- ---- ---- ---- Speaker=Y ---> Speaker=N ---- ---- ---- ---- Speaker=N ---> Speaker=Y ---- ---- ---- ---- ---- ---- cause ---> same --------------------------------------------------------------------- In a positive Close File response (F_CLOSE_FILE_RS(+)) the current Speaker may either: 1. Set Speaker to "Yes" and become the Speaker. 2. Set Speaker to "No" and remain the Listener. The File Transfer service will ensure that the setting of the speaker parameter is consistent with the capabilities of the peer user. The turn is never exchanged in the case of a negative response or confirmation. Only the Speaker is allowed to issue F_XXX_FILE_RQ primitives. 3.3.4 Exchanging the Turn 3.3.4.1 Initial Turn (First Speaker) The Initiator becomes the first Speaker at the end of the Session Setup (F_CONNECT_CF received by Initiator and F_CONNECT_RS sent by Responder). 3.3.4.2 Following Turns Rules: 1. At each unsuccessful End of File the turn is not exchanged. 2. At each successful End of File the turn is exchanged if requested by the Listener:
- The current Listener receives F_CLOSE_FILE_IND
(Speaker = choice).
- If the Listener answers F_CLOSE_FILE_RS(Speaker = YES), it
becomes Speaker, the Speaker receives F_CLOSE_FILE_CF (Speaker =
NO) and becomes Listener.
- If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it
remains Listener, and the Speaker receives F_CLOSE_FILE_CF
(Speaker = YES) and remains Speaker.
3. The Speaker can issue a Change Direction request (F_CD_RQ) to
become the Listener. The Listener receives a Change Direction
indication (F_CD_IND) and becomes the Speaker.
4. In order to prevent loops of F_CD_RQ/IND, it is an error to send
F_CD_RQ immediately after having received a F_CD_IND.
3.3.5 End to End Response
This service is initiated by the current Speaker (if there is no file
transfer in progress) to send an End-to-End response from the final
destination to the originator of a file.
| |
F_EERP_RQ ---->|------------|----> F_EERP_IND
| |
Parameters
Request Indication
------------------------------------
filename -------> same
date -----------> same
time -----------> same
destination ----> same
originator -----> same
------------------------------------
Relationship with Turn:
- Only the Speaker may send an End to End Response request.
- Invoking the EERP service does not change the turn.
- If a F_CD_IND has been received just before F_EERP_RQ is issued,
this results in leaving the special condition created by the
reception of F_CD_IND; i.e. while it was possible to issue
F_RELEASE_RQ and not possible to issue F_CD_RQ just after the
reception of F_CD_IND, after having issued F_EERP_RQ the normal
Speaker status is entered again (F_CD_RQ valid, but F_RELEASE_RQ
not valid).
3.4 Session Take Down
3.4.1 Normal Close
| |
F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND
| |
Parameters
Request Indication
---------------------------------------------------------------------
reason = normal -------> ----
---------------------------------------------------------------------
The Release service can only be initiated by the Speaker.
The Speaker can only issue a Release request (F_RELEASE_RQ) just
after receiving an unsolicited Change Direction indication
(F_CD_IND). This ensures that the other partner doesn't want to send
any more files in this session.
Peer ODETTE-FTP entities action a normal session release by
specifying Reason = Normal in an End Session (ESID) command.
3.4.2 Abnormal close
| |
F_RELEASE_RQ ---->|------------|----> F_ABORT_IND
| |
Parameters
Request Indication
---------------------------------------------------------------------
reason = error value --> same (or equivalent)
AO (Abort Origin) = (L)ocal or (D)istant
---------------------------------------------------------------------
Abnormal session release can be initiated by either the Speaker or
the Listener and also by the user or provider.
Abnormal session release can occur at any time within the session.
Peer ODETTE-FTP entities action an abnormal session release by
specifying Reason = Error-value in an End Session (ESID) command.
The abnormal session release deals with the following types of error:
1. The service provider will initiate an abnormal release in the
following cases:
1. Protocol error, 2. Failure of the Start Session (SSID)
negotiation, 3. Command not recognised, 4. Exchange buffer size
error, 5. Resources not available, 6. Other unspecified abort code
(with "REASON" = unspecified).
2. The User Monitor will initiate an abnormal release in the
following cases:
1. Local site emergency close down, 2. Resources not available, 3.
Other unspecified abort code (with "REASON" = unspecified).
Other error types may be handled by an abort of the connection.
3.4.3 Abort
| |
F_ABORT_RQ ---->|------------|----> F_ABORT_IND
| |
User Initiated Abort
| |
F_ABORT_IND <----|------------|----> F_ABORT_IND
| |
Provider Initiated Abort
Parameters
Request Indication
---------------------------------------------------------------------
-- R (Reason): specified or unspecified
-- AO (Abort Origin): (L)ocal or (D)istant
---------------------------------------------------------------------
The Abort service may be invoked by either entity at any time.
The service provider may initiate an abort in case of error
detection.
3.4.4 Explanation of Session Take Down Services User | OFTP | Network | OFTP | User ---------------|------|----------------------|------|--------------- | | | | 1. Normal Release F_RELEASE_RQ | | ESID(R=normal) | | F_RELEASE_IND *--------------|-> ==|======================|=> --|--------------> (R=normal) | | | | 2. User Initiated Abnormal Release F_RELEASE_RQ | | ESID(R=error) | | F_ABORT_IND *--------------|-> ==|======================|=> -|--------------> (R=error value)| | | | (R=error,AO=D) User | OFTP | Network | OFTP | User ---------------|------|----------------------|------|--------------- | | | | 3. Provider Initiated Abnormal Release F_ABORT_IND | | ESID(R=error) | | F_ABORT_IND <--------------|-* *=|======================|=> --|--------------> | | | | 4. User Initiated Connection Abort F_ABORT_RQ | | N_DISC_RQ | | F_ABORT_IND *--------------|-> --|--------->..----------|-> --|--------------> | | N_DISC_IND | | (R=unsp.,AO=D) 5. Provider Initiated Connection Abort F_ABORT_IND | | N_DISC_RQ | | F_ABORT_IND <--------------|-* *-|--------->..----------|-> --|--------------> (R=error,AO=L) | | N_DISC_IND | | (R=unsp.,AO=D) Key: * Origin of command flow F_ ---> File Transfer Service primitive N_ ---> Network Service primitive ===> ODETTE-FTP (OFTP) protocol message
3.5 Service State Automata This state automata defines the service as viewed by the User Monitor. Events causing a state transition are shown in lower case and the resulting action in upper case where appropriate. 3.5.1 Idle State Diagram o------------o decision | | f_connect_ind +-----------------| IDLE |-----------------+ | F_CONNECT_RQ | (0) | F_CONNECT_RS | | o------------o | V | o-----------------o | | | | | I_WF_FCONNECTCF | | | | | o--------+--------o | | | | F_CONNECT_CF | V V o-----------------o o-----------------o | | | | | IDLE SPEAKER | | IDLE LISTENER | | (1) | | (2) | | See Speaker | | See Listener | | State Diagram | | State Diagram | | | | | o-----------------o o-----------------o
3.5.2 Speaker State Diagram o-----------------o o-----------------o | IDLE LISTENER | | IDLE | | CD_RQ just sent | | see (0) | | see (3), Listen | | Idle | | State Diagram | | State Diagram | o-----------------o o-----------------o A A | | decision decision decision F_CD_RQ +----------------+ F_RELEASE_RQ | | F_EERP_RQ | | o=================o | o-----------------o | |<-------------+ | IDLE SPEAKER | | IDLE SPEAKER | | (4) | | (1) | decision | CD_IND | | |<-----------------------------| just received | o=================o F_EERP_RQ o-----------------o A A | | | | | decision and P1 decision and P1 | | | +-----------------+ +---------------------+ | | F_START_FILE_RQ | | F_START_FILE_RQ | | V V | | o---------------o | | f_file_start_cf(-) | | | +----------------------| OPENING | | | | | o---------------o | | f_file_close_cf(-) f_start_file_cf(+) and not P2 | | V o---------------o o---------------o | | | |------------------+ | CLOSING | | DATA TRANSFER | record to send | | | | |<-----------------+ o---------------o o---------------o F_DATA_RQ | A | | | end of file | | +-------------------+ | F_CLOSE_FILE_RQ | o-----------------o | f_close_file(+) and P2 | IDLE LISTENER | +--------------------------------------------->| see (2), Listen | | State Diagram | Predicates: o-----------------o P1: Mode = Both or (Mode = Sender-Only) P2: Negative confirmation or (positive confirmation, Speaker = YES)
3.5.3 Listener State Diagram o-----------------o o-----------------o | IDLE SPEAKER | | IDLE | | CD_IND just | | | | received see(4) | | see (0) | | Speaker State | | Idle | | Diagram | | State Diagram | o-----------------o o-----------------o A A | | decision f_eerp_ind decision F_CD_IND +--------------+ F_RELEASE_IND | | | | o=================o | o-----------------o | |<-----------+ f_eerp_ind | | | |<-----------------------------| IDLE LISTENER | | IDLE LISTENER | | (3) | | | f_start_file_ind | CD_RQ | | (2) | and not p2 | just sent | | |---------------------+ | | o=================o F_START_FILE_RS(-) | o-----------------o A | A A | | | | | | +-----------------------+ | | | | | | | | | | f_start_file_ind and not p2 | | | | +--------------------------------------+ | | | F_START_FILE_RS(-) | | | | | | f_start_file_ind f_start_file_ind | | | and p2 and p2 | | +-------------------------------+ +------------------+ | F_START_FILE_RS(+) | | F_START_FILE_RS(+) | V V | o---------------o | f_close_file_ind and not p1 | DATA |-------------+ +------------------------------| TRANSFER | | F_CLOSE_FILE_RS(-) | |<------------+ o---------------o F_DATA_IND o---------------o | | IDLE SPEAKER | f_close_file_ind and p1 | | see (1), Spkr |<--------------------------+ | State Diagram | F_CLOSE_FILE_RS(+) o---------------o Predicates: P1: (decision to send F_CLOSE_FILE_RS(+)) and (decision to set Speaker = yes in F_CLOSE_FILE_RS(+)) P2: (decision to send F_START_FILE_RS(+))
(next page on part 2)
