The Hash-Chain Context Transfer Protocol (HCTP)
draft-ruvalcaba-hctp-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 | Cristian Xavier Ruvalcaba | ||
| Last updated | 2026-08-11 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| 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-ruvalcaba-hctp-00
Individual Submission C.X. Ruvalcaba
Internet-Draft Saluca LLC
Intended status: Standards Track 11 August 2026
Expires: 12 February 2027
The Hash-Chain Context Transfer Protocol (HCTP)
draft-ruvalcaba-hctp-00
Abstract
The Hash-Chain Context Transfer Protocol (HCTP) is a payload format
and synchronization protocol for incrementally transferring an
ordered, append-only sequence of conversational context between two
endpoints over a bandwidth-constrained channel. Acknowledged history
is represented by a single fixed-size rolling hash commitment (the
"static root"); only not-yet-acknowledged context blocks (the
"dynamic window") are transmitted. As a result, the per-message wire
overhead attributable to history is constant and independent of the
total number of previously acknowledged turns. HCTP is transport-
agnostic and carries no confidentiality or peer authentication of its
own; it is intended to run over a secure transport. This document
specifies the HCTP data model, wire format, rolling-root computation,
and synchronization state machine.
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 12 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ruvalcaba Expires 12 February 2027 [Page 1]
Internet-Draft HCTP August 2026
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. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Data Model . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Context Block . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Static and Dynamic Sections . . . . . . . . . . . . . . . 5
4. Rolling-Root Computation . . . . . . . . . . . . . . . . . . 5
5. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. SYNC Packet . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. ACK Packet . . . . . . . . . . . . . . . . . . . . . . . 7
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 7
6.1. Per-Role State . . . . . . . . . . . . . . . . . . . . . 7
6.2. Sending a SYNC . . . . . . . . . . . . . . . . . . . . . 8
6.3. Receiving a SYNC . . . . . . . . . . . . . . . . . . . . 8
6.4. Receiving an ACK . . . . . . . . . . . . . . . . . . . . 9
6.5. Retransmission and Loss . . . . . . . . . . . . . . . . . 10
6.6. Error Handling and Re-establishment . . . . . . . . . . . 10
7. Bidirectional Synchronization . . . . . . . . . . . . . . . . 10
8. Verifiable Summaries (Optional) . . . . . . . . . . . . . . . 11
9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 11
10. Transport Considerations . . . . . . . . . . . . . . . . . . 11
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
12.1. HCTP Packet Type Registry . . . . . . . . . . . . . . . 13
12.2. HCTP Version Registry . . . . . . . . . . . . . . . . . 13
12.3. Media Type Registration . . . . . . . . . . . . . . . . 13
13. Normative References . . . . . . . . . . . . . . . . . . . . 13
14. Informative References . . . . . . . . . . . . . . . . . . . 14
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
Ruvalcaba Expires 12 February 2027 [Page 2]
Internet-Draft HCTP August 2026
1. Introduction
Conversational and agentic systems increasingly need to share an
evolving record of interaction ("context") between components:
between a client and a service, between cooperating agents, or
between a live process and a resumable checkpoint. The naive
approach retransmits the entire conversation on every exchange, so
the wire cost grows without bound as the conversation lengthens.
This is wasteful on any channel and prohibitive on a constrained one.
HCTP addresses this by partitioning the context into two parts:
* a *static section* of blocks both endpoints have acknowledged,
represented on the wire by a single 32-octet rolling hash (the
static root); and
* a *dynamic window* of pending blocks that have not yet been
acknowledged, which is the only part transmitted.
Each context block commits to the raw text of one turn via a content
hash and additionally carries a short semantic summary, so that an
endpoint may operate on the summary as context without ever receiving
the raw text, while retaining the ability to verify the block against
the raw text if it later obtains it (Section 8).
HCTP provides ordering and tamper-evidence through a hash chain. It
does *not* provide confidentiality, peer authentication, or non-
repudiation, and its integrity guarantees are meaningful only when it
is carried over a transport that authenticates the peer and protects
the payload (Section 11). HCTP is deliberately independent of any
particular transport: it defines the payload octets, and any datagram
or stream transport MAY carry them.
1.1. Scope and Non-Goals
This document specifies only the transport-agnostic core: the block
format, the rolling-root commitment, the SYNC/ACK exchange, and the
rules for advancing the chain. Mechanisms for peer authentication,
key establishment, message confidentiality, and the specific method
by which a summary is produced are out of scope and are expected to
be supplied by the surrounding system.
Ruvalcaba Expires 12 February 2027 [Page 3]
Internet-Draft HCTP August 2026
2. Conventions and Terminology
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.
Context block: The unit of context corresponding to one
conversational turn (Section 3.1).
Static root: A 32-octet rolling hash committing to the ordered
sequence of acknowledged context blocks.
Dynamic window: The ordered set of pending context blocks not yet
acknowledged by the peer.
SYNC: A packet sent to convey the dynamic window and the current
static root.
ACK: A packet sent to acknowledge a SYNC and report the acknowledged
static root.
Fold: The operation that advances the static root by incorporating
one context block (Section 4).
Sender / Receiver: Roles with respect to a single SYNC exchange. An
endpoint MAY act in both roles; see Section 7.
All multi-octet integers in this document are unsigned and encoded in
network byte order (big-endian). Octet strings written as
hexadecimal are shown for illustration only; on the wire they are raw
octets.
3. Data Model
3.1. Context Block
A context block is a logical record with the following fields:
seq: An unsigned 32-bit sequence number, monotonically increasing
from 0 within a session, identifying the block's position in the
ordered context.
role: A short UTF-8 label identifying the originator of the turn
(for example "user" or "agent"). Its interpretation is
application-defined.
Ruvalcaba Expires 12 February 2027 [Page 4]
Internet-Draft HCTP August 2026
content_hash: The lowercase hexadecimal SHA-256 [RFC6234] digest of
the UTF-8 encoding of the raw turn text.
summary: A UTF-8 semantic summary of the turn, of at most
MAX_SUMMARY_LEN (Section 9) Unicode code points.
For hashing and for on-the-wire serialization, a context block MUST
be encoded as canonical JSON: a JSON object containing exactly the
members "content_hash", "role", "seq", and "summary", with member
names sorted in ascending lexicographic (Unicode code point) order,
no insignificant whitespace, and no member separators other than a
single "," and ":". The canonical encoding of a block B is denoted
canonical(B).
3.2. Static and Dynamic Sections
Each endpoint maintains, per session:
* a static root: a 32-octet value initialized to the genesis root
(Section 4) and advanced only as blocks are acknowledged; and
* a dynamic window: an ordered list of pending context blocks.
Acknowledged blocks are never retransmitted; they are represented
solely by the static root, whose size is constant and independent of
the number of blocks it commits to.
4. Rolling-Root Computation
The static root is a SHA-256 hash chain over acknowledged blocks.
Let "||" denote octet-string concatenation and SHA256(x) denote the
32-octet SHA-256 digest of x.
The genesis root is defined as:
root_0 = SHA256(GENESIS_SEED)
where GENESIS_SEED is the ASCII octet string "hctp-genesis-v1" (15
octets, no trailing NUL).
Given a current root R and a block B, folding B advances the root:
fold(R, B) = SHA256( R || SHA256(canonical(B)) )
The static root after acknowledging blocks B_1, ..., B_n (in order)
is therefore:
root_n = fold( fold( ... fold(root_0, B_1) ..., B_{n-1}), B_n )
Ruvalcaba Expires 12 February 2027 [Page 5]
Internet-Draft HCTP August 2026
Because each root embeds every prior acknowledged root, any
modification, reordering, insertion, or deletion of acknowledged
history produces a different static root, and the mismatch is
detected at the next SYNC (Section 6.3).
5. Wire Format
HCTP defines two packet types, SYNC and ACK. Every packet begins
with a 1-octet version and a 1-octet packet type. The version
specified by this document is 0x01.
5.1. SYNC Packet
0 1 2 3 4 5 6
+--------+--------+--------------------------+
|version | ptype | seq |
| 0x01 | 0x53 | (uint32, 4 octets) |
+--------+--------+--------------------------+
| static_root |
| (32 octets) |
+--------------------------------------------+
| dynamic_len |
| (uint32, 4 octets) |
+--------------------------------------------+
| dynamic_data (dynamic_len octets) |
| ... |
+--------------------------------------------+
| combined_hash |
| (32 octets) |
+--------------------------------------------+
version (1 octet): MUST be 0x01. A receiver MUST reject a packet
with an unknown version.
ptype (1 octet): MUST be 0x53 (ASCII 'S') for SYNC.
seq (4 octets): The sequence number of the last block in the dynamic
window carried by this SYNC.
static_root (32 octets): The sender's current static root, i.e., the
root over all blocks the sender has acknowledged prior to this
SYNC.
dynamic_len (4 octets): The length in octets of dynamic_data.
dynamic_data (dynamic_len octets): A zlib [RFC1950] compressed
Ruvalcaba Expires 12 February 2027 [Page 6]
Internet-Draft HCTP August 2026
stream whose uncompressed content is the canonical JSON array
[canonical(B_i), ...] of the pending context blocks, in ascending
seq order. The array MUST be encoded as canonical JSON (sorted
member names, no insignificant whitespace).
combined_hash (32 octets): SHA256(static_root || dynamic_data),
computed over the static_root field and the compressed
dynamic_data octets exactly as they appear on the wire.
The fixed overhead of a SYNC packet is 74 octets (1 + 1 + 4 + 32 + 4
+ 32), independent of the acknowledged-history depth. The total size
is 74 octets plus dynamic_len.
5.2. ACK Packet
0 1 2 3 4 5 6
+--------+--------+--------------------------+
|version | ptype | seq |
| 0x01 | 0x41 | (uint32, 4 octets) |
+--------+--------+--------------------------+
| new_root |
| (32 octets) |
+--------------------------------------------+
version (1 octet): MUST be 0x01.
ptype (1 octet): MUST be 0x41 (ASCII 'A') for ACK.
seq (4 octets): The seq of the SYNC being acknowledged, echoed
unchanged.
new_root (32 octets): The receiver's static root after folding in
the acknowledged blocks (Section 6.3).
An ACK packet is exactly 38 octets.
6. Protocol Operation
6.1. Per-Role State
The SYNC/ACK exchange is asymmetric, and sender state MUST NOT be
conflated with receiver state. For a given directional chain
(Section 7) an endpoint maintains:
Receiver state:
* local_root: the current static root;
Ruvalcaba Expires 12 February 2027 [Page 7]
Internet-Draft HCTP August 2026
* last_seen_seq: the seq of the most recently accepted SYNC;
* has_seen: a boolean, initially false, set true when the first SYNC
is accepted;
* ack_cache: the most recently sent ACK together with the pre-fold
root over which it was computed.
Sender state:
* static_root: the current static root;
* dynamic: the ordered list of pending blocks;
* next_seq: the seq to assign to the next added block;
* pending_seq: the seq of the outstanding, unacknowledged SYNC, if
any;
* last_acked_seq: the seq of the most recently acknowledged SYNC;
* a retransmit timer and a bounded retransmit counter.
6.2. Sending a SYNC
To transmit pending context, the sender:
1. computes dynamic_data by canonical-JSON-encoding and zlib-
compressing the pending blocks in ascending seq order;
2. sets combined_hash = SHA256(static_root || dynamic_data);
3. sets seq to the seq of the last pending block and records it as
pending_seq;
4. emits the SYNC packet and starts the retransmit timer.
The sender MUST NOT advance its static_root at send time; the root is
advanced only upon receiving a valid ACK (Section 6.4).
6.3. Receiving a SYNC
On receiving a SYNC packet P, the receiver applies the following
checks in order:
Ruvalcaba Expires 12 February 2027 [Page 8]
Internet-Draft HCTP August 2026
1. *Replay.* If has_seen is true and P.seq < last_seen_seq, the SYNC
is a replay of already-superseded state and MUST be silently
discarded. (Note the strict "<": P.seq == last_seen_seq is
handled by the idempotent-retransmit rule below, not discarded
here.)
2. *Idempotent retransmit.* If has_seen is true, P.seq ==
last_seen_seq, and P.static_root equals the pre-fold root
recorded in ack_cache, the SYNC is a retransmission of an
already-processed SYNC whose ACK was lost. The receiver MUST
resend the cached ACK and MUST NOT fold again.
3. *Integrity.* The receiver MUST recompute SHA256(P.static_root ||
P.dynamic_data) and reject the packet if it does not equal
P.combined_hash.
4. *Alignment.* The receiver MUST reject the packet if P.static_root
does not equal its local_root. A mismatch indicates the two
endpoints disagree on acknowledged history and requires re-
establishment (Section 6.6).
5. *Ingest.* The receiver decompresses P.dynamic_data, bounding the
decompressed size (Section 11), parses the canonical JSON block
array, and accepts the blocks as the new pending context.
On acceptance the receiver records pre_fold_root = local_root, folds
each accepted block into local_root in order (Section 4), sets
last_seen_seq = P.seq and has_seen = true, constructs an ACK with
new_root = local_root, records (pre_fold_root, ACK) in ack_cache, and
sends the ACK.
6.4. Receiving an ACK
On receiving an ACK packet A, the sender:
1. ignores A if A.seq != pending_seq (a stale or duplicate ACK), or
if A.seq <= last_acked_seq;
2. otherwise folds each pending block into static_root in order,
producing the sender's updated root;
3. MUST reject the ACK if A.new_root does not equal the sender's
updated root, indicating divergence (Section 6.6);
4. on success clears the dynamic window, sets last_acked_seq =
A.seq, clears pending_seq, and cancels the retransmit timer.
Ruvalcaba Expires 12 February 2027 [Page 9]
Internet-Draft HCTP August 2026
6.5. Retransmission and Loss
If the retransmit timer expires before an ACK is received, the sender
MUST retransmit the SYNC bearing the *unchanged* seq and the
*unchanged* pre-fold static_root, up to a bounded retransmit count.
A single lost ACK MUST NOT cause session re-establishment or re-
keying: the idempotent-retransmit rule (Section 6.3) ensures a
retransmitted SYNC re-elicits the same ACK without double-folding.
Only after the bounded retransmit count is exhausted without
acknowledgment does the sender signal transport failure.
6.6. Error Handling and Re-establishment
A static-root mismatch (either endpoint) means the endpoints no
longer share acknowledged history and cannot be reconciled within
HCTP. Implementations MUST treat this as a fatal session error and
re-establish a new session from genesis. HCTP does not define
reconciliation of divergent chains; such divergence indicates loss,
reordering that escaped detection at a lower layer, or tampering.
The seq field is a 32-bit unsigned integer. An endpoint MUST NOT
allow seq to wrap; upon approaching 2^32 blocks in a session, both
endpoints MUST re-key by starting a new session with a fresh genesis
root. Sessions exceeding 2^32 blocks are not supported.
7. Bidirectional Synchronization
When both endpoints originate context concurrently, a single shared
static root can diverge, because each endpoint would fold blocks in
an order the other cannot reproduce. HCTP resolves this with per-
direction chains: an endpoint pair maintains two independent rolling-
root chains, one advanced solely by folding blocks originated by the
first endpoint and acknowledged by the second, and the other advanced
solely by folding blocks originated by the second endpoint and
acknowledged by the first. A SYNC is associated with a direction,
determined either from the role indicator or from the channel on
which it is received. Because opposite-direction SYNCs fold into
disjoint chains, they cannot diverge.
Alternatively, endpoints MAY serialize all folds onto a single shared
chain using a single-writer turn-token: an endpoint transmits a SYNC
only while holding the turn-token, and the token is conveyed to the
peer upon transmission of an ACK. This yields a single agreed fold
order at the cost of strictly alternating turns. An implementation
MUST use exactly one of these two strategies for a given session and
MUST NOT mix them.
Ruvalcaba Expires 12 February 2027 [Page 10]
Internet-Draft HCTP August 2026
8. Verifiable Summaries (Optional)
An endpoint that lacks the raw turn text MAY operate using the
block's summary as its working context. If the endpoint later
obtains the raw text, it can verify the block by recomputing
content_hash from the raw text and comparing it to the block's
content_hash field.
Implementations MAY additionally make the summary itself reproducible
and thus verifiable, rather than merely asserted, by computing it
with a fixed, pre-agreed deterministic summarization function -- for
example a summarizer identified by name and version, applied with a
fixed prompt or template and a deterministic decoding configuration
-- such that any party holding the raw text and the agreed
configuration recomputes the identical summary. This document does
not mandate any particular summarization function; when determinism
across heterogeneous implementations cannot be guaranteed, an
endpoint MAY instead verify a summary under a pre-agreed equivalence
predicate (for example a canonicalization or a distance threshold).
Absent such a mechanism, the summary MUST be treated as unverified
assertion.
9. Protocol Constants
PROTO_VERSION: 0x01
PTYPE_SYNC: 0x53
PTYPE_ACK: 0x41
GENESIS_SEED: the ASCII octets "hctp-genesis-v1"
MAX_SUMMARY_LEN: 120 (Unicode code points)
Hash function: SHA-256 [RFC6234]
Compression: zlib [RFC1950] / DEFLATE [RFC1951]
10. Transport Considerations
HCTP is transport-agnostic; it defines only the octets of SYNC and
ACK packets. A SYNC or ACK is a self-delimiting unit (its length is
fully determined by its fixed fields plus dynamic_len) and MAY be
carried as a single datagram, a length-framed record on a stream, a
WebSocket [RFC6455] binary message, or the body of an HTTP request or
response. HCTP performs no fragmentation of its own: if a dynamic
payload exceeds the underlying channel's usable size, the sending
application MUST split the pending blocks across multiple SYNC
Ruvalcaba Expires 12 February 2027 [Page 11]
Internet-Draft HCTP August 2026
packets, each bearing the same static_root and an increasing seq, and
reassemble on the receiver.
Because HCTP supplies no confidentiality or peer authentication, it
MUST be carried over a transport that provides them where those
properties are required (Section 11).
11. Security Considerations
*HCTP is not a secure channel by itself.* The static root,
combined_hash, and content_hash are computed with an unkeyed hash
function. They provide tamper-evidence against accidental corruption
and against a party that cannot forge packets, but they provide *no*
cryptographic authentication: an active attacker who can inject
packets can recompute a consistent combined_hash and a consistent
chain for any payload of the attacker's choosing. Authenticity,
integrity against active attackers, and confidentiality MUST be
provided by the underlying transport (for example TLS 1.3 [RFC8446]
or QUIC [RFC9000]) or by an authenticated-encryption layer that wraps
the HCTP packet. Absent such a layer, HCTP's integrity guarantees
are meaningless.
*No non-repudiation.* Either endpoint can construct a valid-looking
chain from genesis; the chain proves internal consistency, not
origin. Binding context to a long-term identity requires signatures
and is out of scope.
*Replay.* Within a session, the seq field and the strict ordering
check reject replays of superseded SYNCs, and the static-root
alignment check rejects out-of-context injection. Cross-session
replay is prevented by starting each session from a fresh genesis and
never reusing session state; endpoints SHOULD bind the session to
transport-layer freshness (for example a fresh TLS session) to
prevent whole-session replay.
*Decompression resource exhaustion.* dynamic_data is attacker-
influenced compressed input. A receiver MUST bound the maximum
accepted decompressed size and the maximum number of blocks per SYNC,
and MUST abort decompression that exceeds those bounds, to avoid a
decompression "bomb" denial of service. dynamic_len itself MUST be
bounded before allocation.
*Confidentiality of summaries.* A block's summary may reveal the
semantic content of a turn even though the raw text is not sent.
Where the summary is sensitive, the transport MUST encrypt the
packet. The content_hash likewise permits confirmation of a guessed
plaintext; where raw texts are low-entropy or guessable, this MUST be
considered.
Ruvalcaba Expires 12 February 2027 [Page 12]
Internet-Draft HCTP August 2026
*Hash agility.* This version fixes SHA-256 and a fixed genesis seed.
Collision resistance of the chain rests entirely on SHA-256. A
future version of the protocol (indicated by the version octet) may
specify an alternative hash; endpoints MUST reject versions they do
not implement.
12. IANA Considerations
12.1. HCTP Packet Type Registry
IANA is requested to create a new registry, "HCTP Packet Types", with
a 1-octet unsigned integer identifier space, under a to-be-assigned
HCTP-protocol registry group. The registration policy is
"Specification Required" [RFC8126]. The initial contents are:
+======================+============+===============+
| Value | Name | Reference |
+======================+============+===============+
| 0x41 | ACK | This document |
+----------------------+------------+---------------+
| 0x53 | SYNC | This document |
+----------------------+------------+---------------+
| 0x00, 0x02-0x40, | Unassigned | |
| 0x42-0x52, 0x54-0xFF | | |
+----------------------+------------+---------------+
Table 1
12.2. HCTP Version Registry
IANA is requested to create a registry "HCTP Versions" with a 1-octet
identifier space, registration policy "Specification Required",
initially containing value 0x01 ("HCTP/1", this document).
12.3. Media Type Registration
IANA is requested to register the "application/hctp" media type for
HCTP packets carried over media-type-aware transports, per the
procedures of [RFC6838]. Type name: application; Subtype name: hctp;
Required parameters: none; Optional parameters: none; Encoding
considerations: binary; Security considerations: see Section 11 of
this document.
13. Normative References
[RFC1950] Deutsch, P. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>.
Ruvalcaba Expires 12 February 2027 [Page 13]
Internet-Draft HCTP August 2026
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Specification
version 1.3", RFC 1951, May 1996,
<https://www.rfc-editor.org/info/rfc1951>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011,
<https://www.rfc-editor.org/info/rfc6234>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
14. Informative References
[RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol",
RFC 6455, December 2011,
<https://www.rfc-editor.org/info/rfc6455>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>.
Acknowledgments
The rolling-root delta-transfer design and the verifiable-summary
block derive from an earlier reference implementation of the
protocol.
Author's Address
Ruvalcaba Expires 12 February 2027 [Page 14]
Internet-Draft HCTP August 2026
Cristian Xavier Ruvalcaba
Saluca LLC
Email: cristian@saluca.com
Ruvalcaba Expires 12 February 2027 [Page 15]