RFC 5024
ODETTE File Transfer Protocol 2.0
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.
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
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
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.
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).
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.
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.
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.
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.
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.
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 same2.2.2. Network Data
N_DATA_RQ ------> N_DATA_IND Data exchange is an unconfirmed service. The requester passes data for transmission to the Network Service via the N_DATA_RQ primitive. The Responder is notified of the availability of data via N_DATA_IND.
In practice, the notification and receipt of data may be combined, such as by the return from a blocking read from the network socket. Parameters Request Indication --------------------------------------------------------------------- Data ------------------> same2.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'.
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
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.
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.
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.
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.
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.
| |
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.
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).
3.4. Session Take Down
3.4.1. Normal Close
| | F_RELEASE_RQ ---->|------------|----> F_RELEASE_IND | | Parameters Request Indication --------------------------------------------------------------------- reason = normal -------> ---- --------------------------------------------------------------------- The Release service can only be initiated by the Speaker. The Speaker can only issue a Release request (F_RELEASE_RQ) just after receiving an unsolicited Change Direction indication (F_CD_IND). This ensures that the other partner doesn't want to send any more files in this session. Peer ODETTE-FTP entities action a normal session release by specifying Reason = Normal in an End Session (ESID) command.3.4.2. Abnormal Close
| | F_RELEASE_RQ ---->|------------|----> F_ABORT_IND | | Parameters Request Indication --------------------------------------------------------------------- reason = error value --> same (or equivalent) AO (Abort Origin) = (L)ocal or (D)istant --------------------------------------------------------------------- Abnormal session release can be initiated by either the Speaker or the Listener and also by the user or provider. Abnormal session release can occur at any time within the session. Peer ODETTE-FTP entities action an abnormal session release by specifying Reason = Error-value in an End Session (ESID) command.
The abnormal session release deals with the following types of error:
1. The service provider will initiate an abnormal release in the
following cases:
1. Protocol error.
2. Failure of the Start Session (SSID) negotiation.
3. Command not recognised.
4. 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.
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 message3.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.
3.5.1. Idle State Diagram
o------------o decision | | f_connect_ind +-----------------| IDLE |-----------------+ | F_CONNECT_RQ | (0) | F_CONNECT_RS | | o------------o | V | o-----------------o | | | | | I_WF_FCONNECTCF | | | | | o--------+--------o | | | | F_CONNECT_CF | V V o-----------------o o-----------------o | | | | | IDLE SPEAKER | | IDLE LISTENER | | (1) | | (2) | | See Speaker | | See Listener | | State Diagram | | State Diagram | | | | | o-----------------o o-----------------o
3.5.2. Speaker State Diagram
o-----------------o o-----------------o | IDLE LISTENER | | IDLE | | CD_RQ just sent | | see (0) | | see (3), Listen | | Idle | | State Diagram | | State Diagram | o-----------------o o-----------------o A A | | decision decision 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
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 | |
| |<-----------------------------| |
| | 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)
