Radio Image Framing Protocol (RIFP)
Internet-Draft<br>RIFP<br>July 2026
Dulaunoy<br>Expires 29 January 2027<br>[Page]
Workgroup:<br>Network Working Group<br>Internet-Draft:<br>draft-dulaunoy-rifp-00<br>Published:
28 July 2026
Intended Status:<br>Experimental<br>Expires:<br>29 January 2027<br>Author:
A. Dulaunoy
Computer Incident Response Center Luxembourg
Radio Image Framing Protocol (RIFP)
Abstract
This document specifies the Radio Image Framing Protocol (RIFP), a compact,<br>unidirectional object-transfer protocol intended for transmitting images over<br>low-rate radio links. RIFP defines independently synchronized frames, a<br>versioned and extensible binary header, fragmentation and reassembly rules, a<br>JSON manifest, per-frame CRC-32 protection, whole-object SHA-256 verification,<br>and registries for future frame types, flags, header extensions, media<br>encodings, and radio profiles.¶
RIFP is independent of a particular frequency allocation or modulation. This<br>document also defines an initial continuous-phase binary frequency-shift keying<br>profile named rifp-cpfsk-4800. The profile can be used on frequencies where<br>local regulation permits such operation; 433.92 MHz is a common deployment<br>example but is not mandated by this specification.¶
Status of This Memo
This Internet-Draft is submitted in full conformance with the<br>provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task<br>Force (IETF). Note that other groups may also distribute working<br>documents as Internet-Drafts. The list of current Internet-Drafts is<br>at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months<br>and may be updated, replaced, or obsoleted by other documents at any<br>time. It is inappropriate to use Internet-Drafts as reference<br>material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 29 January 2027.¶
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the<br>document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with<br>respect to this document.¶
Table of Contents
1. Introduction
Low-rate radio systems are often used to move small telemetry messages, but<br>there are also practical cases for periodically sending weather maps, camera<br>snapshots, diagrams, forms, or facsimile-like monochrome images. Existing<br>analogue facsimile systems generally bind image representation, timing, and<br>modulation into one format. That makes experimentation with compression,<br>packet repetition, stronger integrity checks, or new physical layers harder.¶
RIFP separates three concerns:¶
an image object and its metadata;¶
an extensible fragmentation and framing layer; and¶
a named radio profile describing modulation and synchronization.¶
The initial protocol is intentionally unidirectional. A sender can repeat<br>manifest and data frames to improve reception on lossy channels. Future<br>specifications can add repair requests, forward-error correction,<br>authentication, encryption, or bidirectional operation without redefining the<br>base frame.¶
2. Conventions and Terminology
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT,<br>SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and<br>OPTIONAL in this document are to be interpreted as described in BCP 14<br>[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as<br>shown here.¶
All multi-octet integers are unsigned and encoded in network byte order.<br>Bits within an octet are transmitted most significant bit first.¶
Object:<br>The complete encoded image byte sequence being transferred.¶
Session:<br>One transfer of one object, identified by a 64-bit Session ID.¶
Frame:<br>A complete RIFP protocol data unit consisting of a base header, optional<br>header extensions, payload, and CRC-32 trailer.¶
Radio profile:<br>A named set of physical-layer and synchronization parameters used to carry<br>RIFP frames.¶
Critical extension:<br>A flag or TLV that changes processing in a way that cannot safely be ignored.¶
3. Protocol Overview
A sender performs the following operations:¶
It scales and encodes an image.¶
It assigns a 64-bit Session ID.¶
It constructs a JSON manifest describing the object.¶
It divides the encoded object into numbered chunks.¶
It sends one or more MANIFEST frames, DATA frames for each chunk, and an<br>END frame.¶
It MAY repeat any MANIFEST or DATA frame.¶
A receiver searches for the radio-profile synchronization word, parses the<br>RIFP header, rejects unsupported critical features, validates the frame CRC,<br>and stores valid chunks by Session ID and Sequence Number. Once all chunks<br>are present, the receiver concatenates them in sequence order and validates<br>the complete size, CRC-32, and SHA-256 digest before...