Jason Transfer Protocol (JTP)
draft-baker-jtp-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Matthew Baker | ||
| Last updated | 2026-04-04 (Latest revision 2026-03-31) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
GitHub Repository
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-baker-jtp-00
Independent Submission M. Baker
Internet-Draft Independent
Intended status: Experimental 31 March 2026
Expires: 2 October 2026
Jason Transfer Protocol (JTP)
draft-baker-jtp-00
Abstract
This document specifies the Jason Transfer Protocol (JTP), a compact
binary protocol for listing and transferring images over a reliable
ordered byte stream. JTP is designed to be simple to implement and
efficient to parse. Images are addressed by a content-derived 64-bit
identifier computed using xxHash64. The protocol supports catalog
enumeration, point retrieval by identifier, delta synchronization,
and connection reuse via a keep-alive mechanism. Transport security
may be provided by TLS with an ALPN protocol identifier of "jtp/1".
This document specifies the on-wire format of JTP version 1. It does
not specify any particular implementation.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
[JTP-REPO].
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 2 October 2026.
Baker Expires 2 October 2026 [Page 1]
Internet-Draft Jason Transfer Protocol March 2026
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Connection Reuse (Keep-Alive) . . . . . . . . . . . . . . 5
3. Transport . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. TLS and Application-Layer Protocol Negotiation . . . . . 6
4. Data Types . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Unsigned Integers: u8, u16, u32, u64 . . . . . . . . . . 6
4.2. Variable-Length Integer: varint(u32) . . . . . . . . . . 6
4.3. UTF-8 Strings . . . . . . . . . . . . . . . . . . . . . . 7
5. Identifiers . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. ImageID . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Flags Field . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. File Type Codes . . . . . . . . . . . . . . . . . . . . . 8
6.2. Compression (Bit 3) . . . . . . . . . . . . . . . . . . . 9
6.3. Encryption (Bit 4) . . . . . . . . . . . . . . . . . . . 9
6.4. Reserved Bits (Bits 5-7) . . . . . . . . . . . . . . . . 9
7. Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. RequestFlags . . . . . . . . . . . . . . . . . . . . . . 9
7.2. LIST Request (ReqType = 1) . . . . . . . . . . . . . . . 10
7.3. GET_BY_ID Request (ReqType = 0) . . . . . . . . . . . . . 10
7.4. BATCH Request (ReqType = 2) . . . . . . . . . . . . . . . 11
7.5. LIST_AND_GET Request (ReqType = 5) . . . . . . . . . . . 11
8. Responses . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. LIST Response . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Image Packet . . . . . . . . . . . . . . . . . . . . . . 13
8.3. BATCH Response . . . . . . . . . . . . . . . . . . . . . 14
8.4. LIST_AND_GET Response . . . . . . . . . . . . . . . . . . 15
9. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 15
9.1. Structured ERROR Response . . . . . . . . . . . . . . . . 15
9.2. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 16
9.3. Legacy Error Signaling . . . . . . . . . . . . . . . . . 16
10. Limits and Resource Considerations . . . . . . . . . . . . . 16
11. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 17
Baker Expires 2 October 2026 [Page 2]
Internet-Draft Jason Transfer Protocol March 2026
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
12.1. Transport Security . . . . . . . . . . . . . . . . . . . 18
12.2. Content Integrity . . . . . . . . . . . . . . . . . . . 18
12.3. Denial of Service . . . . . . . . . . . . . . . . . . . 18
12.4. Filename Safety . . . . . . . . . . . . . . . . . . . . 18
12.5. Certificate Validation . . . . . . . . . . . . . . . . . 19
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
14.1. Normative References . . . . . . . . . . . . . . . . . . 19
14.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Varint Encoding Example . . . . . . . . . . . . . . 20
Appendix B. Wire Format Summary . . . . . . . . . . . . . . . . 20
B.1. Request Formats . . . . . . . . . . . . . . . . . . . . . 21
B.2. Response Formats . . . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
The Jason Transfer Protocol (JTP) is a request/response binary
protocol intended for efficient enumeration and retrieval of image
files over a reliable, ordered byte stream such as TCP. JTP
addresses images by a content-derived 64-bit hash (xxHash64),
enabling content integrity checks and delta synchronization without
additional metadata exchange.
JTP is motivated by use cases in which a client must efficiently
synchronize a local image store against a remote server, acquiring
only the subset of images it does not already possess (delta sync).
The protocol is deliberately minimal: it provides catalog listing,
targeted retrieval, batch delta sync, and a combined single-round-
trip operation.
This specification defines:
* The on-wire encoding of all request and response message types.
* The data types, flag fields, and identifier derivation rules used
by the protocol.
* Transport requirements and optional TLS integration.
* Error signaling, resource limits, and extensibility mechanisms.
Baker Expires 2 October 2026 [Page 3]
Internet-Draft Jason Transfer Protocol March 2026
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
1.2. Terminology
Client An endpoint that initiates connections to a server and sends
JTP requests.
Server An endpoint that accepts connections from clients and serves
JTP responses.
ImageID A 64-bit content identifier derived from the raw bytes of an
image file, computed as xxHash64(image_bytes, seed=0).
Varint An unsigned LEB128 (Little-Endian Base 128) encoding of a
32-bit unsigned integer, as defined in Section 4.2.
Catalog The set of (ImageID, flags, filename, size) tuples returned
by a LIST response.
Image Packet The wire encoding of a single image, comprising flags,
length, ImageID, and raw data bytes.
Delta Sync The BATCH operation in which a client sends its set of
known ImageIDs and the server returns only the images the client
does not have.
2. Protocol Overview
JTP is a request/response protocol. A single connection carries one
or more request/response exchanges. A typical interaction proceeds
as follows:
1. The client opens a connection (TCP or TLS-wrapped TCP) to the
server.
2. The client transmits a LIST request (ReqType = 1). The server
replies with a catalog frame containing (ImageID, Flags,
Filename, Size) entries for every image it serves.
3. The client requests images using one of:
Baker Expires 2 October 2026 [Page 4]
Internet-Draft Jason Transfer Protocol March 2026
* GET_BY_ID (ReqType = 0): explicit retrieval of up to 255
images by their ImageIDs.
* BATCH (ReqType = 2): delta sync in which the client provides
all ImageIDs it already holds; the server returns only the
missing images.
* LIST_AND_GET (ReqType = 5): a combined single-round-trip
operation that returns all available images together with
their metadata.
4. The server transmits zero or more image packets, each containing
flags, byte length, ImageID, and raw (possibly compressed) image
data.
2.1. Connection Reuse (Keep-Alive)
JTP supports connection reuse through a keep-alive mechanism. When
enabled, multiple request/response exchanges may be performed over a
single connection, amortizing connection establishment and TLS
handshake costs.
* If the keep-alive flag (bit 0 of RequestFlags) is set in a
request, the server SHOULD keep the connection open after
completing the response and await the next request.
* If the keep-alive flag is not set, the server SHOULD close the
connection after the response has been fully sent.
* Servers MAY implement idle timeouts and close stale keep-alive
connections unilaterally.
* Clients SHOULD NOT assume keep-alive is honored. Clients MUST
handle server-initiated connection closure gracefully at any point
after a complete response has been received.
Legacy deployments MAY use a one-request-per-connection mode: the
client opens a connection, sends exactly one request, reads the
complete response, and then the connection is closed by either party.
3. Transport
JTP requires an ordered, reliable, full-duplex byte stream. The
default and RECOMMENDED transport is TCP. JTP MAY be wrapped in TLS
[RFC8446] to provide confidentiality and integrity for both request
and response data.
Baker Expires 2 October 2026 [Page 5]
Internet-Draft Jason Transfer Protocol March 2026
No default TCP port is assigned by this specification. Deployments
SHOULD document the port(s) they use. The reference implementation
defaults to port 8443.
3.1. TLS and Application-Layer Protocol Negotiation
When TLS is used, servers MAY advertise the following ALPN [RFC7301]
protocol identifier:
* jtp/1
Clients that support ALPN SHOULD offer jtp/1 during the TLS
handshake. A server that does not recognize the offered ALPN
identifier MAY proceed without ALPN selection or abort the handshake.
JTP does not define certificate distribution. Deployments MAY use
self-signed certificates, a locally trusted certificate authority, or
a certificate issued by a public PKI. Clients SHOULD verify the
server certificate according to the applicable PKI policy.
4. Data Types
4.1. Unsigned Integers: u8, u16, u32, u64
JTP uses unsigned integers of 8, 16, 32, and 64 bits. Unless
otherwise specified, all multi-byte fixed-width integers are encoded
in network byte order (big-endian).
4.2. Variable-Length Integer: varint(u32)
The varint(u32) type uses unsigned LEB128 (Little-Endian Base 128)
encoding. LEB128 is described in the DWARF debugging standard and is
in common use in binary protocols (e.g., WebAssembly, Protocol
Buffers). The following properties apply to the JTP varint(u32)
type:
* Encodable range: 0 through 4,294,967,295 (0x00000000 through
0xFFFFFFFF), inclusive.
* Encoded length: 1 to 5 bytes.
* Each byte stores 7 data bits in bits 0 through 6. Bit 7 (0x80) is
the continuation bit; a value of 1 indicates that additional bytes
follow.
Canonical encoding: Implementations SHOULD produce the minimal
(canonical) encoding, i.e., no unnecessary high-order zero groups.
Receivers MAY reject non-canonical encodings as malformed.
Baker Expires 2 October 2026 [Page 6]
Internet-Draft Jason Transfer Protocol March 2026
Example: the value 4660 (0x00001234) encodes as the two-byte sequence
0xB4 0x24. Derivation: 4660 in binary is 0001 0010 0011 0100. Split
into 7-bit groups from least significant: 0110100 (0x34) and 0100100
(0x24 without the continuation bit, giving 0x24 with bit 7 clear for
the final byte). The first byte has bit 7 set: 0xB4. The second
byte is 0x24.
4.3. UTF-8 Strings
Filenames in the catalog are encoded as UTF-8 [RFC3629] byte
sequences. The protocol transmits an explicit byte-length prefix; no
null terminator is used. Receivers SHOULD validate that filename
bytes constitute well-formed UTF-8.
5. Identifiers
5.1. ImageID
An ImageID is a 64-bit unsigned integer computed from the raw bytes
of an image file using the xxHash64 non-cryptographic hash function
with a seed value of zero:
ImageID = xxHash64(image_bytes, seed = 0)
The xxHash64 algorithm is defined in the xxHash specification
[xxHash]. Implementors MUST use seed value 0.
On the wire, ImageID is transmitted as a u64 in big-endian byte
order. When rendered in human-readable form (e.g., log output), the
RECOMMENDED representation is the 16-character lowercase hexadecimal
encoding of the 8 big-endian bytes.
ImageID provides content integrity verification but is NOT a
cryptographic message authentication code (MAC). An adversary with
the ability to modify transmitted data can also forge an ImageID.
Cryptographic integrity of image content requires TLS or an
equivalent channel security mechanism (see Section 12).
6. Flags Field
Both catalog entries and image packets carry a one-octet Flags field.
The bit assignments are:
Baker Expires 2 October 2026 [Page 7]
Internet-Draft Jason Transfer Protocol March 2026
+======+======+============+========================================+
| Bits | Mask | Name | Description |
+======+======+============+========================================+
| 0-2 | 0x07 | FileType | Image file type code (see |
| | | | Section 6.1) |
+------+------+------------+----------------------------------------+
| 3 | 0x08 | Compressed | 1 = image data is Zstd |
| | | | compressed |
+------+------+------------+----------------------------------------+
| 4 | 0x10 | Encrypted | Reserved for future |
| | | | encryption support; MUST be 0 |
+------+------+------------+----------------------------------------+
| 5-7 | 0xE0 | (reserved) | MUST be 0 unless defined by a |
| | | | future extension |
+------+------+------------+----------------------------------------+
Table 1
6.1. File Type Codes
The three-bit FileType sub-field (bits 0-2) encodes the image format:
+======+====================+
| Code | Format |
+======+====================+
| 0 | PNG |
+------+--------------------+
| 1 | JPEG (JFIF / Exif) |
+------+--------------------+
| 2 | WebP |
+------+--------------------+
| 3 | BMP |
+------+--------------------+
| 4 | GIF |
+------+--------------------+
| 5 | Reserved |
+------+--------------------+
| 6 | Reserved |
+------+--------------------+
| 7 | Unknown / Other |
+------+--------------------+
Table 2
If the file type cannot be determined, senders SHOULD use code 7
(Unknown / Other).
Baker Expires 2 October 2026 [Page 8]
Internet-Draft Jason Transfer Protocol March 2026
6.2. Compression (Bit 3)
When bit 3 of the Flags field is set, the image data in the enclosing
image packet (see Section 8.2) is compressed using Zstandard (Zstd)
[RFC8878] at an implementation-defined compression level. Receivers
MUST decompress the data before use or integrity verification.
Integrity verification via xxHash64 (see Section 5.1) MUST be
performed against the decompressed data.
If a receiver does not support Zstd decompression and the Compressed
bit is set, the receiver SHOULD treat the packet as an error and
SHOULD close the connection or send an UnsupportedFeature ERROR
response (see Section 9.2).
6.3. Encryption (Bit 4)
Bit 4 is reserved for future encryption support. Senders MUST set
this bit to 0 in the current version of the protocol. Receivers that
encounter this bit set SHOULD treat the packet as an error.
6.4. Reserved Bits (Bits 5-7)
Bits 5 through 7 are reserved. Senders MUST set reserved bits to 0.
Receivers MAY reject messages containing non-zero reserved bits as
malformed.
7. Requests
Every JTP request begins with a one-octet ReqType field that
identifies the request type. Requests that support connection reuse
carry a second one-octet RequestFlags field immediately following
ReqType.
7.1. RequestFlags
+=====+============+===========================+
| Bit | Name | Description |
+=====+============+===========================+
| 0 | keep-alive | 1 = request connection |
| | | keep-alive after response |
+-----+------------+---------------------------+
| 1-7 | (reserved) | MUST be 0 unless defined |
| | | by a future extension |
+-----+------------+---------------------------+
Table 3
Baker Expires 2 October 2026 [Page 9]
Internet-Draft Jason Transfer Protocol March 2026
Servers MUST reject requests that have any reserved RequestFlags bit
set to 1 by either closing the connection or transmitting an
InvalidRequest ERROR response (see Section 9.2).
7.2. LIST Request (ReqType = 1)
The LIST request asks the server to return a complete catalog of the
images it currently serves. It carries no additional payload beyond
the fixed two-octet header.
+==============+======+===============+====================+
| Field | Type | Size (octets) | Description |
+==============+======+===============+====================+
| ReqType | u8 | 1 | Value: 1 |
+--------------+------+---------------+--------------------+
| RequestFlags | u8 | 1 | Bit 0 = keep-alive |
+--------------+------+---------------+--------------------+
Table 4
The server responds with a LIST response as defined in Section 8.1.
7.3. GET_BY_ID Request (ReqType = 0)
The GET_BY_ID request asks the server to return the image data for a
specified set of ImageIDs.
+=================+======+===============+========================+
| Field | Type | Size (octets) | Description |
+=================+======+===============+========================+
| ReqType | u8 | 1 | Value: 0 |
+-----------------+------+---------------+------------------------+
| RequestFlags | u8 | 1 | Bit 0 = keep-alive |
+-----------------+------+---------------+------------------------+
| Count | u8 | 1 | Number of ImageIDs (N) |
+-----------------+------+---------------+------------------------+
| ImageID[0..N-1] | u64 | 8 x N | Requested IDs, big- |
| | | | endian |
+-----------------+------+---------------+------------------------+
Table 5
Semantics:
* N MAY be zero, in which case no ImageID fields are present and the
server returns zero image packets.
* N MUST NOT exceed 255 (the maximum value of a u8).
Baker Expires 2 October 2026 [Page 10]
Internet-Draft Jason Transfer Protocol March 2026
* Servers MAY silently ignore ImageIDs that are not present in the
catalog.
Response framing: The GET_BY_ID response does not include an explicit
top-level count. Clients SHOULD read exactly N image packets (as
defined in Section 8.2). Servers that silently skip unknown IDs will
therefore produce fewer than N image packets; clients MUST be
prepared for this. If the keep-alive flag is set, the connection
remains open after the last image packet.
7.4. BATCH Request (ReqType = 2)
The BATCH request implements delta synchronization. The client
provides the complete set of ImageIDs it already holds; the server
responds with only those images the client does not have.
+=================+=============+===============+================+
| Field | Type | Size (octets) | Description |
+=================+=============+===============+================+
| ReqType | u8 | 1 | Value: 2 |
+-----------------+-------------+---------------+----------------+
| RequestFlags | u8 | 1 | Bit 0 = keep- |
| | | | alive |
+-----------------+-------------+---------------+----------------+
| HaveCount | varint(u32) | 1-5 | Number of |
| | | | ImageIDs (N) |
+-----------------+-------------+---------------+----------------+
| ImageID[0..N-1] | u64 | 8 x N | IDs the client |
| | | | already has |
+-----------------+-------------+---------------+----------------+
Table 6
Semantics:
* The server computes the set difference (server catalog) minus
(client's HaveSet) and returns exactly those images.
* Servers SHOULD reject BATCH requests in which HaveCount exceeds
1,000,000, responding with an InvalidRequest ERROR.
The server responds with a BATCH response as defined in Section 8.3.
7.5. LIST_AND_GET Request (ReqType = 5)
The LIST_AND_GET request retrieves all available images in a single
round trip, without a prior LIST exchange. The server returns all
images together with their ImageIDs; no separate catalog is needed.
Baker Expires 2 October 2026 [Page 11]
Internet-Draft Jason Transfer Protocol March 2026
+==============+======+===============+====================+
| Field | Type | Size (octets) | Description |
+==============+======+===============+====================+
| ReqType | u8 | 1 | Value: 5 |
+--------------+------+---------------+--------------------+
| RequestFlags | u8 | 1 | Bit 0 = keep-alive |
+--------------+------+---------------+--------------------+
Table 7
No additional payload. The server responds with a LIST_AND_GET
response as defined in Section 8.4.
8. Responses
Each response type begins with a four-octet ASCII magic header that
allows receivers to identify the response type and detect framing
errors.
8.1. LIST Response
The LIST response carries the server's image catalog. It begins with
the fixed frame:
+===============+=======+===============+====================+
| Field | Type | Size (octets) | Description |
+===============+=======+===============+====================+
| Header | bytes | 4 | ASCII "JTPL" (0x4A |
| | | | 0x54 0x50 0x4C) |
+---------------+-------+---------------+--------------------+
| Count | u16 | 2 | Number of catalog |
| | | | entries (N) |
+---------------+-------+---------------+--------------------+
| Entry[0..N-1] | - | variable | Repeated N times |
| | | | (see below) |
+---------------+-------+---------------+--------------------+
Table 8
Each catalog entry has the following structure:
Baker Expires 2 October 2026 [Page 12]
Internet-Draft Jason Transfer Protocol March 2026
+==========+=============+==========+===========================+
| Field | Type | Size | Description |
| | | (octets) | |
+==========+=============+==========+===========================+
| ImageID | u64 | 8 | Content identifier, big- |
| | | | endian |
+----------+-------------+----------+---------------------------+
| Flags | u8 | 1 | File type and feature |
| | | | flags (see Section 6) |
+----------+-------------+----------+---------------------------+
| NameLen | u16 | 2 | Byte length of Filename |
+----------+-------------+----------+---------------------------+
| Filename | bytes | NameLen | UTF-8 basename of the |
| | | | image file |
+----------+-------------+----------+---------------------------+
| Size | varint(u32) | 1-5 | Byte length of image data |
| | | | in the corresponding |
| | | | image packet |
+----------+-------------+----------+---------------------------+
Table 9
Notes:
* Size is the byte count of the data field that will appear in an
image packet for this ImageID. If the Compressed flag is set,
Size reflects the compressed data length.
* Filenames are informational only. Clients SHOULD NOT trust or use
path components from filenames. Clients SHOULD sanitize filenames
before using them as local filesystem paths.
8.2. Image Packet
Image packets are the common unit of image delivery used by the
GET_BY_ID, BATCH, and LIST_AND_GET responses.
Baker Expires 2 October 2026 [Page 13]
Internet-Draft Jason Transfer Protocol March 2026
+=========+=============+===============+=========================+
| Field | Type | Size (octets) | Description |
+=========+=============+===============+=========================+
| Flags | u8 | 1 | File type and feature |
| | | | flags (see Section 6) |
+---------+-------------+---------------+-------------------------+
| Length | varint(u32) | 1-5 | Byte length of Data |
+---------+-------------+---------------+-------------------------+
| ImageID | u64 | 8 | Content identifier, |
| | | | big-endian |
+---------+-------------+---------------+-------------------------+
| Data | bytes | Length | Raw (possibly |
| | | | compressed) image bytes |
+---------+-------------+---------------+-------------------------+
Table 10
Integrity verification: After receiving an image packet (and
decompressing if the Compressed flag is set), receivers SHOULD
verify:
ImageID == xxHash64(Data, seed = 0)
If verification fails, receivers SHOULD discard the data and SHOULD
treat the condition as a transmission error. Continuing to process
corrupt data is NOT RECOMMENDED.
8.3. BATCH Response
+================+=============+===============+====================+
| Field | Type | Size | Description |
| | | (octets) | |
+================+=============+===============+====================+
| Header | bytes | 4 | ASCII "JTPB" (0x4A |
| | | | 0x54 0x50 0x42) |
+----------------+-------------+---------------+--------------------+
| MissingCount | varint(u32) | 1-5 | Number of missing |
| | | | images (M) |
+----------------+-------------+---------------+--------------------+
| Packet[0..M-1] | - | variable | M image packets |
| | | | (see Section 8.2) |
+----------------+-------------+---------------+--------------------+
Table 11
The client reads exactly M image packets following the header.
Baker Expires 2 October 2026 [Page 14]
Internet-Draft Jason Transfer Protocol March 2026
8.4. LIST_AND_GET Response
+================+=======+===============+====================+
| Field | Type | Size (octets) | Description |
+================+=======+===============+====================+
| Header | bytes | 4 | ASCII "JTPG" (0x4A |
| | | | 0x54 0x50 0x47) |
+----------------+-------+---------------+--------------------+
| Count | u16 | 2 | Number of images |
| | | | (N) |
+----------------+-------+---------------+--------------------+
| Packet[0..N-1] | - | variable | N image packets |
| | | | (see Section 8.2) |
+----------------+-------+---------------+--------------------+
Table 12
The client reads exactly N image packets. Because each image packet
contains the ImageID, no separate catalog is required.
9. Error Handling
9.1. Structured ERROR Response
Servers that wish to provide machine-readable error information MAY
transmit a structured ERROR response in place of the expected
response frame:
+============+=======+===============+======================+
| Field | Type | Size (octets) | Description |
+============+=======+===============+======================+
| Header | bytes | 4 | ASCII "JTPE" (0x4A |
| | | | 0x54 0x50 0x45) |
+------------+-------+---------------+----------------------+
| ErrorCode | u8 | 1 | Numeric error code |
| | | | (see Section 9.2) |
+------------+-------+---------------+----------------------+
| MessageLen | u16 | 2 | Byte length of |
| | | | Message |
+------------+-------+---------------+----------------------+
| Message | bytes | MessageLen | UTF-8 human-readable |
| | | | error description |
+------------+-------+---------------+----------------------+
Table 13
Baker Expires 2 October 2026 [Page 15]
Internet-Draft Jason Transfer Protocol March 2026
9.2. Error Codes
+======+====================+=================================+
| Code | Name | Description |
+======+====================+=================================+
| 1 | NotFound | One or more requested resources |
| | | were not found |
+------+--------------------+---------------------------------+
| 2 | InvalidRequest | The request was malformed or |
| | | violated a protocol constraint |
+------+--------------------+---------------------------------+
| 3 | ServerError | An internal server error |
| | | occurred |
+------+--------------------+---------------------------------+
| 4 | UnsupportedFeature | A requested feature is not |
| | | supported by this server |
+------+--------------------+---------------------------------+
| 5 | RateLimited | The request was refused because |
| | | a rate limit was exceeded |
+------+--------------------+---------------------------------+
Table 14
9.3. Legacy Error Signaling
Servers MAY signal errors by closing the TCP connection or
terminating the TLS session without sending a structured ERROR
response. Clients MUST handle the following conditions as request
failure:
* Unexpected TCP or TLS connection closure (EOF) before the response
has been fully received.
* A response magic header that does not match any known value
("JTPL", "JTPB", "JTPG", "JTPE").
* A reserved Flags or RequestFlags bit set to 1.
* A varint that is non-canonical or encodes a value exceeding
0xFFFFFFFF.
* Any other decoding error that prevents the message from being
parsed as specified in this document.
10. Limits and Resource Considerations
JTP implementations SHOULD defend against resource exhaustion attacks
arising from large field values. In particular:
Baker Expires 2 October 2026 [Page 16]
Internet-Draft Jason Transfer Protocol March 2026
* varint(u32) values that, when used as allocation sizes, would
exhaust available memory SHOULD be rejected. Implementations MAY
impose per-field upper bounds lower than 4,294,967,295.
* Oversized NameLen values (e.g., values that would require reading
more bytes than remain in the anticipated message) SHOULD be
rejected.
* Large Count or HaveCount values SHOULD be checked before
allocating memory proportional to them.
Because the Length and Size fields are encoded as varint(u32), the
maximum single image data payload supported by this framing is
4,294,967,295 octets (2^32 - 1, approximately 4 GiB).
Implementations MAY enforce stricter per-image size limits
appropriate to their deployment context.
Servers SHOULD reject BATCH requests in which HaveCount exceeds
1,000,000 by transmitting an InvalidRequest ERROR response.
11. Extensibility
JTP version 1 is designed to accommodate future evolution without
breaking existing implementations:
* Unassigned ReqType values (currently: 3, 4, and values 6-255) are
reserved. Future documents MAY define their semantics. Servers
receiving an unrecognized ReqType SHOULD respond with an
UnsupportedFeature ERROR and close the connection.
* Reserved Flags bits (bits 5-7) and reserved RequestFlags bits
(bits 1-7) MUST remain 0 in version 1 messages. Future extensions
MAY assign meaning to these bits via a new specification.
Receivers MUST be able to handle (or reject) messages with
previously undefined bits set.
* The Encrypted flag (Flags bit 4) is reserved for a future
encryption layer definition. This specification does not define
the encryption scheme; a future document will do so.
A future versioning scheme for the protocol as a whole MAY be
introduced through one or more of the following mechanisms:
* A new ALPN protocol identifier (e.g., jtp/2) negotiated during TLS
handshake.
* A new ReqType value designated for capability negotiation.
Baker Expires 2 October 2026 [Page 17]
Internet-Draft Jason Transfer Protocol March 2026
* Explicit version magic fields in a revised framing layer.
12. Security Considerations
12.1. Transport Security
Deployments SHOULD use TLS [RFC8446] to protect JTP connections
against passive eavesdropping and active tampering. Without TLS,
both image content and ImageIDs are transmitted in the clear, and an
on-path attacker may modify image data or inject fabricated
responses.
12.2. Content Integrity
The xxHash64-derived ImageID provides a non-cryptographic integrity
check against accidental corruption (e.g., transmission bit errors).
It does NOT provide security against a malicious actor, who can
compute a valid xxHash64 over any chosen payload. Applications that
require cryptographic integrity assurance MUST rely on TLS record-
layer integrity or a separate authenticated mechanism.
12.3. Denial of Service
Servers SHOULD validate and bound all count and size fields before
allocating memory or performing I/O proportional to those values.
Specific recommendations:
* Reject BATCH requests with HaveCount exceeding 1,000,000.
* Enforce maximum image sizes appropriate to the deployment.
* Enforce keep-alive idle timeouts to reclaim connection resources
from inactive clients.
* Apply request rate limiting (e.g., using the RateLimited error
code) to mitigate abusive clients.
12.4. Filename Safety
Filenames in the catalog are informational. Clients MUST NOT use
catalog filenames as filesystem paths without first sanitizing them.
In particular, clients MUST strip or reject path separators, relative
path components (e.g., ".." sequences), and any characters not valid
in the target filesystem. Failure to do so may allow a malicious
server to write files to unintended locations (path traversal).
Baker Expires 2 October 2026 [Page 18]
Internet-Draft Jason Transfer Protocol March 2026
12.5. Certificate Validation
When TLS is used, clients SHOULD validate the server's certificate
against a trusted trust anchor appropriate to the deployment. The
use of self-signed certificates or a local CA is acceptable in
controlled environments but introduces risks if the trust anchor is
compromised or mis-deployed.
13. IANA Considerations
This document has no IANA actions at this time. A future revision of
this specification MAY request registration of the following:
* The ALPN Protocol ID jtp/1 in the "TLS Application-Layer Protocol
Negotiation (ALPN) Protocol IDs" registry [RFC7301].
* A TCP port number for JTP in the "Service Name and Transport
Protocol Port Number Registry".
* A registry for JTP ReqType values.
* A registry for JTP Error Codes.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", also known as BCP 14, BCP 14,
RFC 2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003,
<https://www.rfc-editor.org/rfc/rfc3629>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014,
<https://www.rfc-editor.org/rfc/rfc7301>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Baker Expires 2 October 2026 [Page 19]
Internet-Draft Jason Transfer Protocol March 2026
[RFC8878] Collet, Y. and M. Kucherawy, Ed., "Zstandard Compression
and the 'application/zstd' Media Type", RFC 8878, February
2021, <https://www.rfc-editor.org/rfc/rfc8878>.
14.2. Informative References
[JTP-REPO] Matt, "punctuations/jtp: High-performance binary protocol
for efficient image transfer over TCP", 2026,
<https://github.com/punctuations/jtp>.
[xxHash] Collet, Y., "xxHash - Extremely Fast Non-Cryptographic
Hash Algorithm", 2023,
<https://cyan4973.github.io/xxHash/>.
Appendix A. Varint Encoding Example
This appendix illustrates the unsigned LEB128 (varint(u32)) encoding
used by JTP for the value 4660 (0x00001234).
Step 1: Represent the value in binary (14 significant bits):
4660 = 0001 0010 0011 0100 (binary)
Step 2: Group into 7-bit chunks from least significant to most
significant (padding to a multiple of 7 if necessary):
Chunk 0 (least significant): 011 0100 = 0x34
Chunk 1 (most significant): 010 0100 = 0x24
Step 3: Set the continuation bit (bit 7 = 0x80) on all but the final
chunk:
Byte 0: 0x34 | 0x80 = 0xB4 (more bytes follow)
Byte 1: 0x24 = 0x24 (final byte, continuation bit clear)
Encoded result: 0xB4 0x24 (2 bytes).
Decoding: multiply Chunk 1 by 2^7 (128) and add Chunk 0: 36 * 128 +
52 = 4608 + 52 = 4660.
Appendix B. Wire Format Summary
The following diagrams provide a compact summary of each message
format. All fields are transmitted left-to-right, top-to-bottom as
written. Fields labelled "var" have variable length as described in
the corresponding section.
Baker Expires 2 October 2026 [Page 20]
Internet-Draft Jason Transfer Protocol March 2026
B.1. Request Formats
LIST (ReqType = 1):
+----------+----------+
| ReqType | ReqFlags |
| (0x01) | (u8) |
+----------+----------+
GET_BY_ID (ReqType = 0):
+----------+----------+-------+-------- - - --------+
| ReqType | ReqFlags | Count | ImageID[0..N-1] |
| (0x00) | (u8) | (u8) | N x u64 big-endian |
+----------+----------+-------+-------- - - --------+
BATCH (ReqType = 2):
+----------+----------+-------------+-------- - - --------+
| ReqType | ReqFlags | HaveCount | ImageID[0..N-1] |
| (0x02) | (u8) | varint(u32) | N x u64 big-endian |
+----------+----------+-------------+-------- - - --------+
LIST_AND_GET (ReqType = 5):
+----------+----------+
| ReqType | ReqFlags |
| (0x05) | (u8) |
+----------+----------+
B.2. Response Formats
Baker Expires 2 October 2026 [Page 21]
Internet-Draft Jason Transfer Protocol March 2026
LIST response ("JTPL"):
+--------+--------+-------+------ - - ------+
| "JTPL" | Count | Entries |
| 4 bytes| (u16) | N x catalog entry (var) |
+--------+--------+-------+------ - - ------+
Catalog entry:
+---------+-------+---------+----------+------+
| ImageID | Flags | NameLen | Filename | Size |
| (u64) | (u8) | (u16) | NameLen | var |
+---------+-------+---------+----------+------+
Image packet (used in GET_BY_ID, BATCH, LIST_AND_GET responses):
+-------+--------+---------+------ - ------+
| Flags | Length | ImageID | Data |
| (u8) | (var) | (u64) | Length bytes |
+-------+--------+---------+------ - ------+
BATCH response ("JTPB"):
+--------+--------------+------ - - ------+
| "JTPB" | MissingCount | Images |
| 4 bytes| varint(u32) | M x image pkt |
+--------+--------------+------ - - ------+
LIST_AND_GET response ("JTPG"):
+--------+-------+------ - - ------+
| "JTPG" | Count | Images |
| 4 bytes| (u16) | N x image pkt |
+--------+-------+------ - - ------+
ERROR response ("JTPE"):
+--------+-----------+------------+-- - - --+
| "JTPE" | ErrorCode | MessageLen | Message |
| 4 bytes| (u8) | (u16) | var |
+--------+-----------+------------+-- - - --+
Author's Address
Matthew Baker
Independent
Canada
Email: hey@mattt.space
URI: https://github.com/punctuations/jtp
Baker Expires 2 October 2026 [Page 22]