tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5024

 Errata 
Informational
Pages: 135
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: ~proto

ODETTE File Transfer Protocol 2.0

Part 1 of 4, p. 1 to 27
None       Next RFC Part

Obsoletes:    2204


Top       ToC       Page 1 
Network Working Group                                          I. Friend
Request for Comments: 5024                                        ODETTE
Obsoletes: 2204                                            November 2007
Category: Informational


                    ODETTE File Transfer Protocol 2

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.

IESG Note

   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and in particular notes that the decision to publish is not
   based on IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

Abstract

   This memo updates the ODETTE File Transfer Protocol, an established
   file transfer protocol facilitating electronic data interchange of
   business data between trading partners, to version 2.

   The protocol now supports secure and authenticated communication over
   the Internet using Transport Layer Security, provides file
   encryption, signing, and compression using Cryptographic Message
   Syntax, and provides signed receipts for the acknowledgement of
   received files.

   The protocol supports both direct peer-to-peer communication and
   indirect communication via a Value Added Network and may be used with
   TCP/IP, X.25, and ISDN-based networks.

Top       Page 2 
Table of Contents

   1. Introduction ....................................................4
      1.1. Background .................................................4
      1.2. Summary of Features ........................................5
      1.3. General Principles .........................................5
      1.4. Structure ..................................................6
      1.5. Virtual Files ..............................................6
      1.6. Service Description ........................................9
      1.7. Security ...................................................9
   2. Network Service ................................................11
      2.1. Introduction ..............................................11
      2.2. Service Primitives ........................................11
      2.3. Secure ODETTE-FTP Session .................................12
      2.4. Port Assignment ...........................................12
   3. File Transfer Service ..........................................13
      3.1. Model .....................................................13
      3.2. Session Setup .............................................14
      3.3. File Transfer .............................................16
      3.4. Session Take Down .........................................20
      3.5. Service State Automata ....................................23
   4. Protocol Specification .........................................28
      4.1. Overview ..................................................28
      4.2. Start Session Phase .......................................28
      4.3. Start File Phase ..........................................30
      4.4. Data Transfer Phase .......................................34
      4.5. End File Phase ............................................35
      4.6. End Session Phase .........................................36
      4.7. Problem Handling ..........................................36
   5. Commands and Formats ...........................................37
      5.1. Conventions ...............................................37
      5.2. Commands ..................................................37
      5.3. Command Formats ...........................................37
      5.4. Identification Code .......................................68
   6. File Services ..................................................69
      6.1. Overview ..................................................69
      6.2. File Signing ..............................................69
      6.3. File Encryption ...........................................70
      6.4. File Compression ..........................................70
      6.5. V Format Files - Record Lengths ...........................70
   7. ODETTE-FTP Data Exchange Buffer ................................71
      7.1. Overview ..................................................71
      7.2. Data Exchange Buffer Format ...............................71
      7.3. Buffer Filling Rules ......................................72
   8. Stream Transmission Buffer .....................................73
      8.1. Introduction ..............................................73
      8.2. Stream Transmission Header Format .........................73

Top      ToC       Page 3 
   9. Protocol State Machine .........................................74
      9.1. ODETTE-FTP State Machine ..................................74
      9.2. Error Handling ............................................75
      9.3. States ....................................................76
      9.4. Input Events ..............................................79
      9.5. Output Events .............................................79
      9.6. Local Variables ...........................................80
      9.7. Local Constants ...........................................81
      9.8. Session Connection State Table ............................82
      9.9. Error and Abort State Table ...............................85
      9.10. Speaker State Table 1 ....................................86
      9.11. Speaker State Table 2 ....................................91
      9.12. Listener State Table .....................................93
      9.13. Example ..................................................96
   10. Miscellaneous .................................................97
      10.1. Algorithm Choice .........................................97
      10.2. Cryptographic Algorithms .................................97
      10.3. Protocol Extensions ......................................97
      10.4. Certificate Services .....................................98
   11. Security Considerations .......................................98
   Appendix A. Virtual File Mapping Example .........................100
   Appendix B. ISO 646 Character Subset .............................103
   Appendix C. X.25 Specific Information ............................104
      C.1. X.25 Addressing Restrictions .............................104
      C.2. Special Logic ............................................105
      C.3. PAD Parameter Profile ....................................116
   Appendix D. OFTP X.25 Over ISDN Recommendation ...................118
      D.1. ODETTE ISDN Recommendation ...............................119
      D.2. Introduction to ISDN .....................................120
      D.3. Equipment Types ..........................................123
      D.4. Implementation ...........................................124
   Acknowledgements .................................................132
   Normative References .............................................132
   Informative References ...........................................133
   ODETTE Address ...................................................134

Top      ToC       Page 4 
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.

   ODETTE-FTP allows business applications to exchange files on a peer-
   to-peer basis in a standardised, purely automatic manner and provides
   a defined acknowledgement process on successful receipt of a file.

   ODETTE-FTP is not to be confused as a variant of, or similar to, the
   Internet FTP [FTP], which provides an interactive means for
   individuals to share files and which does not have any sort of
   acknowledgement process.  By virtue of its interactive nature, lack
   of file acknowledgements, and client/server design, FTP does not
   easily lend itself to mission-critical environments for the exchange
   of business data.

   Over the last ten years, ODETTE-FTP has been widely deployed on
   systems of all sizes from personal computers to large mainframes
   while the Internet has emerged as the dominant international network,
   providing high-speed communication at low cost.  To match the demand
   for EDI over the Internet, ODETTE has decided to extend the scope of
   its file transfer protocol to incorporate security functions and
   advanced compression techniques to ensure that it remains at the
   forefront of information exchange technology.

   The protocol now supports secure and authenticated communication over
   the Internet using Transport Layer Security, provides file
   encryption, signing, and compression using Cryptographic Message
   Syntax, and provides signed receipts for the acknowledgement of
   received files.

   The protocol supports both direct peer-to-peer communication and
   indirect communication via a Value Added Network and may be used with
   TCP/IP, X.25 and ISDN based networks.

   ODETTE-FTP has been defined by the ODETTE Security Working Group
   which consists of a number of ODETTE member organisations.  All
   members have significant operational experience working with and
   developing OFTP and EDI solutions.

Top      ToC       Page 5 
1.2.  Summary of Features

   This memo is a development of version 1.4 of ODETTE-FTP [OFTP] with
   these changes/additions:

      Session level encryption
      File level encryption
      Secure authentication
      File compression
      Signed End to End Response (EERP)
      Signed Negative End Response (NERP)
      Maximum permitted file size increased to 9 PB (petabytes)
      Virtual file description added
      Extended error codes

   Version 1.4 of ODETTE-FTP included these changes and additions to
   version 1.3:

      Negative End Response (NERP)
      Extended Date and Time stamp
      New reason code 14 (File direction refused)

1.3.  General Principles

   The aim of 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 of file
      storage and 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).

Top      ToC       Page 6 
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 the model.

   The description of 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.

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      ToC       Page 7 
                              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
   detailed in Sections 1.5.1 to 1.5.4.

1.5.1.  Organisation

   Sequential

      Logical records are presented one after another.  ODETTE-FTP must
      be aware of the record boundaries.

1.5.2.  Identification

   Dataset Name

      Dataset name of the Virtual File being transferred, assigned by
      bilateral agreement.

Top      ToC       Page 8 
   Time stamp (HHMMSScccc)

      A file qualifier indicating the time the Virtual File was made
      available for transmission.  The counter (cccc=0001-9999) gives
      higher resolution.

   Date stamp (CCYYMMDD)

      A file qualifier indicating the date the Virtual File was made
      available for transmission.

   The Dataset Name, Date, and Time attributes are assigned by the
   Virtual File's originator and are used to uniquely identify a file.
   They are all mandatory and must not be changed by intermediate
   locations.

   The User Monitor may use the Virtual File Date and Time attributes in
   local processes involving date comparisons and calculations.  Any
   such use falls outside the scope of this protocol.

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 that delimit
         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.

Top      ToC       Page 9 
   The restart position is always calculated relative to the start of
   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.

1.7.  Security

   ODETTE-FTP provides a number of security services to protect a
   Virtual File transmission across a hostile network.

   These security services are as follows:

      Confidentiality
      Integrity
      Non-repudiation of receipt
      Non-repudiation of origin
      Secure authentication

   Security services in this specification are implemented as follows:

      Session level encryption
      File level encryption
      Signed files
      Signed receipts
      Session level authentication
      ODETTE-FTP Authentication

   Session level encryption provides data confidentiality by encryption
   of all the protocol commands and data exchanged between two parties,
   preventing a third party from extracting any useful information from
   the transmission.

Top      ToC       Page 10 
   This session level encryption is achieved by layering ODETTE-FTP over
   Transport Layer Security [TLS], distinguishing between secure and
   unsecure TCP/IP traffic using different port numbers.

   File encryption provides complementary data confidentiality by
   encryption of the files in their entirety.  Generally, this
   encryption occurs prior to transmission, but it is also possible to
   encrypt and send files while in session.  File encryption has the
   additional benefit of allowing a file to remain encrypted outside of
   the communications session in which it was sent.  The file can be
   received and forwarded by multiple intermediaries, yet only the final
   destination will be able to decrypt the file.  File encryption does
   not encrypt the actual protocol commands, so trading partner EDI
   codes and Virtual File names are still viewable.

   Secure authentication is implemented through the session level
   authentication features available in [TLS] and proves the identity of
   the parties wishing to communicate.

   ODETTE-FTP Authentication also provides an authentication mechanism,
   but one that is integral to ODETTE-FTP and is available on all
   network infrastructures over which ODETTE-FTP is operated (this is in
   contrast to [TLS] which is generally only available over TCP/IP-based
   networks).  Both parties are required to possess certificates when
   ODETTE-FTP Authentication is used.

   The security features in ODETTE-FTP 2 are centred around the use of
   [X.509] certificates.  To take advantage of the complete range of
   security services offered in both directions, each party is required
   to possess an [X.509] certificate.  If the confidentiality of data
   between two parties is the only concern, then [TLS] alone can be
   used, which allows the party accepting an incoming connection (the
   Responder) to be the only partner required to possess a certificate.

   For businesses, this means that session level encryption between a
   hub and its trading partners can be achieved without requiring all
   the trading partners to obtain a certificate, assuming that trading
   partners always connect to the hub.

   With the exception of [TLS], all the security services work with X.25
   and ISDN as transport media.  Although nothing technically precludes
   [TLS] from working with X.25 or ISDN, implementations are rare.

Top      ToC       Page 11 
2.  Network Service

2.1.  Introduction

   ODETTE-FTP peer entities communicate with each other via the OSI
   Network Service or the Transmission Control Protocol Transport
   Service [RFC793].  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 its OPEN request upon receipt of
   N_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.

Top      ToC       Page 12 
   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.  Its 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.  Secure ODETTE-FTP Session

   [TLS] provides a mechanism for securing an ODETTE-FTP session over
   the Internet or a TCP network.  ODETTE-FTP is layered over [TLS],
   distinguishing between secure and unsecure traffic by using different
   server ports.

   The implementation is very simple.  Layer ODETTE-FTP over [TLS] in
   the same way as layering ODETTE-FTP over TCP/IP.  [TLS] provides both
   session encryption and authentication, both of which may be used by
   the connecting parties.  A party acts as a [TLS] server when
   receiving calls and acts as a [TLS] client when making calls.  When
   the [TLS] handshake has completed, the responding ODETTE-FTP may
   start the ODETTE-FTP session by sending the Ready Message.

2.4.  Port Assignment

   An 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'.

Top      ToC       Page 13 
   The responding ODETTE-FTP will listen for secure TLS connections on
   Registered Port 6619; the service name is 'odette-ftps'.

3.  File Transfer Service

   The File Transfer Service describes the services offered by an
   ODETTE-FTP entity to its User Monitor (generally an application).

   NOTE: The implementation of the service primitives is an application
         issue.

3.1.  Model

          o-------------------o             o-------------------o
          |                   |             |                   |
          |   USER  MONITOR   |             |   USER  MONITOR   |
          |                   |             |                   |
          o-------------------o             o-------------------o
                  |   A                             |   A
                  |   |                             |   |
      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
                  |   |                             |   |
                  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      ToC       Page 14 
3.2.  Session Setup

3.2.1.  Session Connection Service

   These diagrams represent the interactions between two communicating
   ODETTE-FTP entities and their respective User Agents.

   The vertical lines represent the ODETTE-FTP entities.  The User
   Agents are not shown.

                             |            |
           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
   authentication1-> same -----------> authentication2-> 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      ToC       Page 15 
   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:
         Y         The entity can restart file transfers.
         N         The entity cannot restart file transfers.

      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
   ---------------------------------------------------------------------

   Authentication

      Specifies the authentication requirement of the User Monitor.

      Value:
         Y             Authentication required.
         N             Authentication not required.

      Negotiation:     Not negotiable.

Top      ToC       Page 16 
   Request           Indication        Response          Confirm
   ---------------------------------------------------------------------
   auth = Y    ----> auth = Y    ----> auth = Y    ----> auth = Y

   auth = N    ----> auth = N    ----> auth = N    ----> auth = 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(-)
   ------------------------------------------------------------------
   filename-------> same   ----           ----    ----          ----
   date-time------> same   ----           ----    ----          ----
   destination----> same   ----           ----    ----          ----
   originator-----> same   ----           ----    ----          ----
   rec-format-----> same   ----           ----    ----          ----
   rec-size ------> same   ----           ----    ----          ----
   file-size------> same   ----           ----    ----          ----
   org-file-size--> same   ----           ----    ----          ----
   signed-eerp----> same   ----           ----    ----          ----
   cipher---------> same   ----           ----    ----          ----
   sec-services---> same   ----           ----    ----          ----
   compression----> same   ----           ----    ----          ----
   envelope-format> same   ----           ----    ----          ----
   description----> 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.

Top      ToC       Page 17 
3.3.2.  Data Regime

                             |            |
              F_DATA_RQ ---->|------------|----> F_DATA_IND
                             |            |
              F_DATA_CF <----|(---CDT----)|
                             |            |

   Note: Unlike other commands, where the F_XXX_CF signal is a result of
      a corresponding F_XXX_RS command, in this case, the local entity
      layer issues this signal when it is ready for the next data
      request.  This decision is based on the current credit count and
      the reception of CDT (Set Credit) from the receiver.

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
   Listener may either:

      1.  Set Speaker to "Yes" and become the Speaker or
      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.

Top      ToC       Page 18 
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 the Speaker, the Speaker receives F_CLOSE_FILE_CF
        (Speaker = NO) and becomes the Listener.

      - If the Listener answers F_CLOSE_FILE_RS(Speaker = NO), it
        remains as the Listener, and the Speaker receives
        F_CLOSE_FILE_CF (Speaker = YES) and remains as the 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, the Speaker may not send
      an F_CD_RQ after receiving an unsolicited F_CD_IND.  If the
      Listener receives a solicited F_CD_IND as a result of sending
      EFPA(Speaker=Yes), it is acceptable to immediately relinquish the
      right to speak by sending an F_CD_RQ.

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.

Top      ToC       Page 19 
                             |            |
              F_EERP_RQ ---->|------------|----> F_EERP_IND
                             |            |
              F_RTR_CF  <----|------------|<---- F_RTR_RS
                             |            |

   Parameters

   Request               Indication
   ------------------------------------
   filename -----------> same
   date ---------------> same
   time ---------------> same
   destination --------> same
   originator ---------> same
   hash ---------------> same
   signature ----------> 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 an 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).

   Notes:

   1. The F_EERP_RQ (and also F_NERP_RQ) is confirmed with an F_RTR_CF
      signal.  The F_RTR_CF signal is common to both F_EERP_RQ and
      F_NERP_RQ.  There should be no ambiguity, since there can only be
      one such request pending at any one time.

   2. The signature is optional and is requested when sending the
      F_START_FILE_RQ.

   3. If it is not possible to sign the EERP, then an unsigned EERP
      should still be sent.

Top      ToC       Page 20 
   4. It is an application implementation issue to validate the contents
      of the EERP and its signature and to decide what action to take on
      receipt of an EERP that fails validation or is not signed when a
      signed EERP was requested.

3.3.6.  Negative End Response

   This service is initiated by the current speaker (if there is no file
   transfer in progress) to send a Negative End Response when a file
   could not be transmitted to the next destination.  It is sent only if
   the problem is of a non-temporary kind.

   This service may also be initiated by the final destination instead
   of sending an End to End Response when a file could not be processed,
   after having successfully received the file.

                             |            |
              F_NERP_RQ ---->|------------|----> F_NERP_IND
                             |            |
              F_RTR_CF  <----|------------|----- F_RTR_RS
                             |            |

   Parameters

   Request                          Indication
   ---------------------------------------------------
   filename ----------------------> same
   date --------------------------> same
   time --------------------------> same
   destination -------------------> same
   originator --------------------> same
   creator of negative response --> same
   reason ------------------------> same
   reason text -------------------> same
   hash --------------------------> same
   signature ---------------------> same
   ---------------------------------------------------

   Relationship with Turn:

   The same as for the End-To-End response (see Section 3.3.5).

Top      ToC       Page 21 
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.

Top      ToC       Page 22 
   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. Data 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      ToC       Page 23 
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)

   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

   These state automata define 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.

Top      ToC       Page 24 
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      ToC       Page 25 
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
        F_CD_RQ                                         F_RELEASE_RQ
            |                                                |
   o================o decision  o----------o decision  o---------------o
   |                |---------->| WAIT FOR |<----------|               |
   |                | F_EERP_RQ |          | F_EERP_RQ |               |
   |     IDLE       |           | EERP/    |           |    IDLE       |
   |   SPEAKER      | decision  | NERP     | decision  |   SPEAKER     |
   |     (1)        |---------->| CONFIRM. |<----------|     (4)       |
   |                | F_NERP_RQ |          | F_NERP_RQ |               |
   |                |           |          |           |               |
   |                |           |          |           |    CD_IND     |
   |                | f_rtr_cf  |          |           | just received |
   |                |<----------|          |           |               |
   |                |           o----------o           |               |
   |                |                                  |               |
   |                |                                  |               |
   o================o                                  o---------------o
     A  A        |                                               |
     |  |        | decision and P2              decision and P2  |
     |  |        +-----------------+       +---------------------+
     |  |         F_START_FILE_RQ  |       |    F_START_FILE_RQ
     |  |                          V       V
     |  |                      o---------------o
     |  |  f_file_start_cf(-)  |               |
     |  +----------------------|    OPENING    |
     |                         |               |
     |                         o---------------o
     |                                 |
   f_file_close_cf(-) or          f_start_file_cf(+)
   f_file_close_cf(+) and not P1       |
     |                                 V

Top      ToC       Page 26 
   o---------------o     o---------------o  record to send   o---------o
   |               |     |               |------------------>|         |
   |    CLOSING    |     | DATA TRANSFER |     F_DATA_RQ     | NEXT    |
   |               |     |               |                   | RECORD  |
   |               |     |               |     f_data_cf     |         |
   |               |     |               |<------------------|         |
   o---------------o     o---------------o                   o---------o
     |         A                   |
     |         |    end of file    |
     |         +-------------------+
     |            F_CLOSE_FILE_RQ
     |                                              o-----------------o
     |                f_file_close_cf(+) and P1     |  IDLE LISTENER  |
     +--------------------------------------------->| see (2), Listen |
                                                    |  State Diagram  |
   Predicates:                                      o-----------------o
   P1: Positive confirmation and Speaker = YES
   P2: Mode = Both or (Mode = Sender-only)

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
            |      |   F_RTR_RS   |                          |
   o=================o            |                 o-----------------o
   |                 |<-----------+                 |                 |
   |                 |                              |                 |
   |                 | f_nerp_ind                   |                 |
   |                 |------------+                 |                 |
   |                 | F_RTR_RS   |                 |                 |
   |                 |            |                 |                 |
   |                 |<-----------+                 |                 |
   |  IDLE LISTENER  |                 f_eerp_ind   |  IDLE LISTENER  |
   |       (2)       |<-----------------------------|       (3)       |
   |                 |                 F_RTR_RS     |      CD_RQ      |
   |                 |                              |    just sent    |
   |                 |                 f_nerp_ind   |                 |
   |                 |<-----------------------------|                 |

Top      ToC       Page 27 
   |                 |                 F_RTR_RS     |                 |
   |                 |                              |                 |
   |                 | f_start_file_ind             |                 |
   |                 |    and not P1                |                 |
   |                 |---------------------+        |                 |
   o=================o F_START_FILE_RS(-)  |        o-----------------o
     A A    |   A  A                       |           |          |
     | |    |   |  +-----------------------+           |          |
     | |    |   |                                      |          |
     | |    |   | f_start_file_ind and not P1          |          |
     | |    |   +--------------------------------------+          |
     | |    |            F_START_FILE_RS(-)                       |
     | |    |                                                     |
     | |    |        f_start_file_ind           f_start_file_ind  |
     | |    |           and P1                        and P1      |
     | |    +----------------------------+     +------------------+
     | |             F_START_FILE_RS(+)  |     | F_START_FILE_RS(+)
     | |                                 V     V
     | |                            o---------------o
     | |f_close_file_ind and not P3 |               |
     | +----------------------------|               |
     |    F_CLOSE_FILE_RS(+,N)      |               |
     |                              |     DATA      |
     |                              |   TRANSFER    |
     |  f_close_file_ind and not P2 |               |-------------+
     +------------------------------|               |             |
          F_CLOSE_FILE_RS(-)        |               |<------------+
                                    o---------------o  F_DATA_IND
   o---------------o                           |
   | IDLESPEAKER  |  f_close_file_ind and P3  |
   | see (1), Spkr |<--------------------------+
   | State Diagram |    F_CLOSE_FILE_RS(+,Y)
   o---------------o

   Predicates:
   P1: Decision to send F_START_FILE_RS(+)
   P2: Decision to send F_CLOSE_FILE_RS(+)
   P3: Decision to become Speaker


Next RFC Part