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, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, August 2018, . 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, . 14.2. Informative References [JTP-REPO] Matt, "punctuations/jtp: High-performance binary protocol for efficient image transfer over TCP", 2026, . [xxHash] Collet, Y., "xxHash - Extremely Fast Non-Cryptographic Hash Algorithm", 2023, . 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]