OFTP2 — ODETTE File Transfer Protocol 2

The historical transport protocol of the European automotive industry, ported to TCP/IP in 2007 with end-to-end security, restart-on-interrupt and signed receipts. Specified by RFC 5024 (Informational).

What is OFTP2?

OFTP was defined in 1986 by Odette (Organisation for Data Exchange by Tele Transmission in Europe) working group #4 to address EDI requirements of the European automotive industry (RFC 5024 §1.1). Where internet FTP is interactive and lacks acknowledgement, OFTP is designed from the start as a peer-to-peer protocol for automatic file transfer between applications, with a mandatory functional acknowledgement.

OFTP 1.x ran over X.25 and ISDN. OFTP2 (2007) ports the protocol to TCP/IP while preserving backwards compatibility — the same command grammar wrapped differently at the network layer. The main additions of OFTP2 over OFTP 1.4 are: session encryption and authentication via TLS, file-level encryption and signing via CMS, signed receipts (signed EERP), maximum file size raised to 9 PB, extended virtual-file description, and enriched error codes (RFC 5024 §1.2).

The Virtual File model

All information exchanged between two OFTP2 entities flows as a Virtual File (RFC 5024 §1.5). A Virtual File is defined by a set of attributes; the mapping to a local file on each side is left to the implementation. The main attributes:

• Dataset Name — logical identifier, agreed bilaterally. This is the business attribute used to find the shipment on the application side.
• Date stamp (CCYYMMDD) and Time stamp (HHMMSScccc) — qualify the instant the file was made available. Together with the Dataset Name they form the Virtual File's unique identity, which no intermediary may change (§1.5.2).
• Record Format — four formats: Fixed (records of equal length), Variable (varying lengths), Unstructured (octet stream), Text (ASCII sequence delimited by CR-LF, lines < 2048 characters) (§1.5.3).
• Restart position — resume position negotiated when the transfer opens (§1.5.4).

Commands and session phases

OFTP2 is a stateful protocol with a fixed ASCII command grammar. The main commands (RFC 5024 §5.2):

Sender (Speaker)                Receiver (Listener)
───────────────                 ────────────────────
  TLS Handshake ───────────────────────►
                                        ◄──────── TLS Ready
  SSRM Start Session Ready Msg ────────►
       ◄──────── SSID Start Session (Id, Pwd, mode, restart)
  SSID Start Session ──────────────────►
       ◄──────── SFID Start File (dataset, date, size, restart=0)
  SFID Start File ─────────────────────►
       ◄──────── SFPA Start File Positive Ack (answer count)
  DATA blocks (CDT credits) ───────────►
       ◄──────── CDT  Set Credit
  ...
  EFID End File (record count) ────────►
       ◄──────── EFPA End File Positive Ack
  ESID End Session (normal) ───────────►
       ◄──────── ESID End Session Echo
  TCP close
                              (later, sometimes much later)
                                        ───► EERP End-to-End Response (signed CMS)
       ◄──────── EERP Echoed

# Resume after interruption — on an unfinished file.
# The receiver has already persisted N octets; it offers
# to resume at offset 1024 * N (1024-octet blocks, §1.5.4).

Speaker                              Listener
SFID dataset=ORDERS_2026_0514          ───►
                                       ◄─── SFPA answercount=512   (offset 512 ko)
DATA resumed from offset 512 KB        ───►
...
EFID End File                          ───►
                                       ◄─── EFPA
ESID End Session                       ───►
                                       ◄─── ESID Echo
TCP close

Security — TLS, X.509, CMS signing

OFTP2 provides five security services (RFC 5024 §1.7): confidentiality, integrity, non-repudiation of receipt, non-repudiation of origin, and secure authentication. They are implemented at two stackable levels:

• Session level — TLS encryption and X.509-based authentication on the TCP connection. The distinction between secured and unsecured traffic is made through the port (§1.7, §2.3).
• File level — CMS encryption and signing (Cryptographic Message Syntax, RFC 3852) applied to the Virtual File payload itself. File-level encryption keeps the data encrypted outside the session, so intermediaries (VAN, hubs) can forward a file that only the final recipient will decrypt (§1.7).

Real-world certificates are X.509 RSA, typically 2048 bits, with SHA-256. Enrolment between two partners means exchanging public certificates out-of-band and dropping them into the partner profile on each OFTP2 station — exactly like AS2. On recommended algorithms, Odette 2024 guidance is TLS 1.2 minimum (TLS 1.3 where the product supports it) and AES-256-GCM for file encryption.

EERP, NERP — the signed receipts

OFTP2 distinguishes two acknowledgement levels. The EFPA (End File Positive Answer) is a receipt at the protocol level — the Listener confirms it persisted the file. That is a technical signal that closes the transfer phase.

The actual application-level acknowledgement is the EERP (End-to-End Response), emitted later by the business recipient after its application has effectively consumed the file. The EERP carries the Dataset Name and the original date/time, and in OFTP2 may be signed in CMS. That signed EERP provides the cryptographic non-repudiation of receipt required by automotive contracts. On a business refusal, the recipient emits a NERP (Negative End Response, added in OFTP 1.4 and kept in OFTP2), also signable.

The EERP/NERP need not arrive on the original transfer session: it can be routed later, even through a third node (Odette multi-hop network). That decoupling between technical reception and signed application acknowledgement is what makes OFTP2 resilient to session interruptions.

Ports and infrastructure

OFTP2 uses two TCP ports registered with IANA (RFC 5024 §2.4):

• 3305 / TCP — service odette-ftp, cleartext session. Avoid on the public internet; acceptable inside VPN or MPLS.
• 6619 / TCP — service odette-ftps, OFTP2 session over TLS. Standard port for any modern internet deployment.

Beyond peer-to-peer, OFTP2 supports multi-hop routing (§3.3) where a file traverses a chain of intermediate mailboxes (Odette hubs, sectoral VANs) before reaching its final destination. This topology is typical of three- or four-tier automotive supply chains.

The European automotive industry

OFTP2 is mainstream across European automotive. Per Odette's public information, mandating manufacturers include Audi, BMW, Daimler/Mercedes-Benz, Ford Europe, Hyundai, MAN, Scania, Skoda, Stellantis (PSA + FCA), Volkswagen and Volvo, plus "most Tier 1 suppliers" (Bosch, Continental, Valeo, ZF, Magna, Faurecia/Forvia, Schaeffler).

The payloads are essentially EDIFACT messages in the Odette subset (or VDA, the German subset). The most frequent ones:

• DELFOR — rolling delivery forecast emitted by the OEM over a 6 to 12-month horizon.
• DELJIT — synchronous delivery calls, hourly granularity for JIT/JIS lines, driven by production sequencing.
• DESADV — despatch advice, indispensable for automated Goods Received on the OEM side.
• INVOIC — invoice, sometimes self-billed by the OEM.

Outside European automotive, OFTP2 is marginal: other verticals have moved to AS2 (retail), AS4 (PEPPOL), or never left SFTP. So an EDI vendor addressing automotive MUST support OFTP2; elsewhere it is dispensable.

Operational pitfalls

• Mismatched "Both" mode. The SSID-negotiable mode between Sender-only, Receiver-only and Both can land on an unexpected asymmetry (RFC 5024 §3.2.1) — one partner believes it is in Both, the other negotiated it down to Receiver-only. Files never leave. Always pin the mode in the partner profile.
• Restart position lost after crash. If the OFTP2 agent doesn't persist the received offset frequently, a mid-transfer crash voids the restart and forces full retransmission. Critical for multi-gigabyte DELFOR files.
• EERP expected but never signed. On a legacy OFTP 1.4 partner, the EERP can't be signed. If the contract requires cryptographic NRR, switch to OFTP2 or double the acknowledgement channel.
• Confusing session vs. file certificate. Like AS4, OFTP2 uses two distinct certificates: TLS for the session and a separate X.509 for CMS file signing/encryption. Mixing them creates authentication incidents where one believes "everything is fine because the session connects".
• Multi-hop routing and NRR. If the file traverses a hub, the NRR must propagate end-to-end. Verify that the hub forwards the signed EERP from the final recipient and doesn't generate its own intermediate EERP.

Official sources

• RFC 5024 — ODETTE File Transfer Protocol 2 (November 2007) — the canonical text (276 953 octets, archived locally in content/_sources/rfc/rfc5024_OFTP2.txt).
• RFC 2204 — ODETTE File Transfer Protocol (1997) — the X.25/ISDN predecessor, now obsolete but useful to understand the command grammar.
• Odette OFTP2 Experts Group — the official maintainer, publishing implementation guides and the list of conformant products.
• RFC 3852 — Cryptographic Message Syntax (CMS) — the cryptographic base of OFTP2 file signing and encryption.

Further reading

• The five EDI transport families compared — to position OFTP2 against AS2, AS4, SFTP and VAN.
• AS2 — the dominant alternative outside European automotive.
• AS4 — the OASIS profile adopted for PEPPOL and eDelivery.
• EDIFACT DELFOR D.96A and DELJIT D.96A — the typical OFTP2 payloads in automotive.