Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 2204

ODETTE File Transfer Protocol

Pages: 74
Obsoleted by:  5024
Part 1 of 3 – Pages 1 to 21
None   None   Next

ToP   noToC   RFC2204 - Page 1
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
ToP   noToC   RFC2204 - Page 2
   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
ToP   noToC   RFC2204 - Page 3
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).
ToP   noToC   RFC2204 - Page 4
   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.
ToP   noToC   RFC2204 - Page 5
                              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.
ToP   noToC   RFC2204 - Page 6
   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.
ToP   noToC   RFC2204 - Page 7
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.
ToP   noToC   RFC2204 - Page 8
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.
ToP   noToC   RFC2204 - Page 9
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.
ToP   noToC   RFC2204 - Page 10
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
ToP   noToC   RFC2204 - Page 11
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.
ToP   noToC   RFC2204 - Page 12
   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
   ---------------------------------------------------------------------
ToP   noToC   RFC2204 - Page 13
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.
ToP   noToC   RFC2204 - Page 14
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:
ToP   noToC   RFC2204 - Page 15
      - 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
ToP   noToC   RFC2204 - Page 16
      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.
ToP   noToC   RFC2204 - Page 17
   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.
ToP   noToC   RFC2204 - Page 18
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
ToP   noToC   RFC2204 - Page 19
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
ToP   noToC   RFC2204 - Page 20
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)
ToP   noToC   RFC2204 - Page 21
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)

Next Section