Tech-invite3GPPspaceIETF RFCsSIP
929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5024

ODETTE File Transfer Protocol 2.0

Pages: 135
Informational
Errata
Obsoletes:  2204
Updated by:  8996
Part 1 of 4 – Pages 1 to 27
None   None   Next

Top   ToC   RFC5024 - 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   ToC   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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   RFC5024 - 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 page on part 2)

Next Section