Internet-Draft TIBET TAT October 2026
van de Meent Expires 2 May 2027 [Page]
Workgroup:
Internet Engineering Task Force
Internet-Draft:
draft-vandemeent-tibet-tat-01
Published:
Intended Status:
Standards Track
Expires:
Author:
J. van de Meent
Humotica

TIBET TAT: Touch-and-Transfer Protocol

Abstract

This document specifies TIBET TAT, a Touch-and-Transfer protocol for moving sealed continuity-bearing objects across proximity, relay, and local-network handoff lanes.

TAT defines a consent-bound handoff model, a seed exchange for tunnel establishment, encrypted chunk streaming, mutual transfer anchoring between sender and receiver, and the rules under which the carrier of an in-flight transfer may change.

TAT does not define identity truth, semantic class, or sealed object class by itself. Instead, it defines the wire and handoff layer that carries such objects once sender and receiver have agreed to transfer. TAT is intended to sit between the Continuity Envelope Protocol (CEP) and higher-level application profiles such as IDDrop.

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 May 2027.

▲

Table of Contents

1. Introduction

Many systems can transport bytes, but fewer specify the exact handoff semantics of a consensual sealed transfer.

TIBET TAT addresses this gap. TAT is the wire and handoff protocol for touch-and-transfer and related relay delivery paths.

The key design principle is simple: transfer MUST be consent-bound, anchored, and sealed.

This revision keeps the model of -00 and tightens it where building the pieces revealed ambiguity: the tunnel key schedule, a store-and-forward mode, chunk topology, the separation between arrival and admission, receipts for refused outcomes, and the handling of a carrier change during a transfer. Appendix "Changes from -00" lists every change.

2. 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.

TAT
The Touch-and-Transfer protocol specified in this document.
Seed
A compact signed handshake object exchanged before tunnel opening.
Consent
The explicit receiver-side decision to accept, reject, or request more information before transfer continues.
Transfer Pair
The sender-side transfer_out anchor and receiver-side transfer_in anchor that together record a single handoff event.
TAT Tunnel
The encrypted transport channel established after seed validation and consent.
Tombstone
An optional finality record written after successful transfer to indicate deactivation or succession.
Carrier
The actor or device that currently bears an in-flight transfer or the task it belongs to. A carrier is distinct from the transport substrate (the lane) that moves bytes.
Handoff Edge
A signed record declaring that the carrier of a transfer changes from one named actor to another within the same task (Section 9).
Arrival
The event of sealed bytes reaching a receiver or its rendezvous point. Arrival is a custody fact, not a decision.
Admission
The receiver-side decision that arrived material may be opened, materialized, or acted upon. Admission is always evaluated fresh by the receiver and is never inherited from an earlier step.
Receipt
A record of the outcome of a TAT step, written for acceptances and refusals alike.
Decider
The evaluation that reached an outcome, as distinct from the key or runtime that signed the record of it.

3. Protocol Overview

TAT sits between general continuity messaging and higher-level application protocols. TIBET decides causal truth [CAUSAL], TAT decides transfer flow, ICC or TZA/TBZ sealed carriers decide object structure, and SSM [SSM] decides visible dispatch surface.

TAT is intended as the generic transfer profile that a specialized application profile MAY build upon.

TAT MAY be used across multiple transport modes including proximity touch, local relay, local network handoff, and HTTP-assisted handoff. The transport substrate MAY vary, but the TAT consent, tunnel, and transfer-pair semantics MUST remain invariant.

TAT operates in one of two modes:

Interactive mode
Sender and receiver are both reachable during the transfer. Consent precedes content flow and both sides contribute ephemeral key material (Section 5).
Store-and-forward mode
The receiver is not reachable when the sender transfers. The sender seals content to a receiver static key and a relay or rendezvous point holds the sealed carrier until the receiver collects it (Section 6).

A relay that accepts a sealed carrier takes custody of opaque bytes. Custody by a relay MUST NOT be interpreted as delivery to the receiver, and delivery MUST NOT be interpreted as receiver consent or admission.

4. TAT Objects

Seed Object
Advertises transfer intent and carries minimum material for validation and tunnel setup (Section 4.1).
Consent Object
The receiver-side signed response that echoes the transfer identifier and states accept, reject, or request_more.
Transfer-Out Anchor
The sender-side record of initiated transfer. It MUST be written before protected content flows.
Transfer-In Anchor
The receiver-side record of received and verified transfer. It MUST only be written after integrity verification succeeds. It SHOULD reference the corresponding transfer_out anchor as its causal parent, so that both halves of a cross-device transfer form one causal chain.
Optional Tombstone
An optional finality object recording deactivation or succession after transfer.
Handoff Edge
The signed declaration of a carrier change (Section 9).
Receipt
The outcome record of a TAT step (Section 10).

4.1. Minimum Seed Contents

A Seed Object MUST carry at least:

  • the transfer_pair_id;
  • a reference to the sender identity and the sender's signature verification key, or a fingerprint of it;
  • the sender's ephemeral X25519 public key;
  • the intended receiver;
  • an expiry or freshness indication;
  • an algorithm identifier for the tunnel construction;
  • a signature by the sender over a canonical encoding of all of the above.

A Seed Object MAY additionally carry a digest of sealed content when content accompanies the seed (store-and-forward mode). When present, the digest MUST be covered by the seed signature, so that the sealed body cannot be spliced under a different header.

Seed fields that are visible in clear are routing and recognition hints. They MUST NOT be treated as verified until the signature has been checked, and the sender verification key MUST be checked against the key registered for the claimed sender identity. A key that arrives inside the object it authenticates proves internal consistency only, not provenance.

5. Touch-and-Transfer Flow

  1. sender generates an ephemeral X25519 keypair and a new transfer_pair_id
  2. sender emits a Seed Object
  3. receiver validates the seed and performs consent
  4. receiver emits a signed Consent Object
  5. sender verifies consent
  6. sender writes transfer_out
  7. both sides derive the tunnel key
  8. encrypted chunks are streamed
  9. receiver verifies final integrity and writes transfer_in
  10. sender MAY write a tombstone

A relay or HTTP flow follows the same logical sequence. Implementations MUST NOT weaken bilateral consent, transfer-pair integrity, or receiver binding merely because the transport is not NFC-based.

Steps 3 to 5 are independent of the carrier and transport. Whether the seed travelled by proximity, QR code, relay, or local network, the receiver performs the same validation and the sender performs the same consent verification.

6. Store-and-Forward Mode

When the receiver cannot take part in a live exchange, the sender MAY seal content to a static X25519 key that the receiver has published for this purpose. In this mode:

  1. the sender generates a fresh ephemeral X25519 keypair for this transfer and performs ECDH against the receiver static key;
  2. the sender derives the tunnel key as in Section 7, encrypts the content, and binds it to a signed seed header that carries the content digest;
  3. the sender writes transfer_out before releasing the sealed carrier to a relay or rendezvous point;
  4. the receiver collects the carrier and runs the arrival stages of Section 8;
  5. only after arrival verification and receiver-side consent does the receiver open or materialize the content and write transfer_in.

Because content travels before the receiver consents, the Bilateral Consent rule (Section 11) applies at the point of opening rather than at the point of transmission: a receiver MUST NOT open, materialize, or act on store-and-forward content before it has verified the carrier and made an explicit consent decision. Only the holder of the receiver static key can derive the tunnel key, so a carrier delivered to the wrong receiver fails authenticated decryption rather than relying on a routing check.

Store-and-forward mode does not provide forward secrecy with respect to the receiver static key (Section 14). Interactive mode SHOULD be preferred when both parties are reachable.

7. Tunnel Establishment

TAT seeds are RECOMMENDED to be encoded compactly, for example using CBOR [RFC8949], when the seed must traverse a narrow proximity channel.

TAT RECOMMENDS X25519 for ephemeral ECDH [RFC7748] and HKDF-SHA256 [RFC5869] for deriving a per-transfer tunnel key and nonce prefix.

The transfer itself SHOULD use an authenticated encryption scheme such as AES-256-GCM [RFC5116]. Chunks MUST be sequenced and integrity checked, and the receiver MUST compare the final result to the sender's summary before writing transfer_in.

7.1. Key Schedule

When X25519, HKDF-SHA256, and AES-256-GCM are used, the tunnel material is derived as follows, where shared is the X25519 shared secret and tpid is the transfer_pair_id encoded as an octet string:

tunnel_key   = HKDF-SHA256(IKM = shared, salt = tpid,
                           info = "AInternet-Airdrop-Tunnel-v1",
                           L = 32)
nonce_prefix = HKDF-SHA256(IKM = shared, salt = tpid,
                           info = "AInternet-Airdrop-Tunnel-v1"
                                  || 0x01,
                           L = 8)
nonce(i)     = nonce_prefix || uint32_be(i)      ; 12 octets
ciphertext_i = AES-256-GCM(tunnel_key, nonce(i), chunk_i,
                           aad = tpid)

The info strings are protocol constants. Implementations that need a different construction MUST use a different algorithm identifier in the seed rather than reuse these labels.

The following requirements apply:

  • The ephemeral X25519 key MUST be freshly generated for each transfer. Because the salt is the transfer_pair_id, a reused ephemeral key combined with a reused transfer_pair_id would reproduce the same key and nonce sequence.
  • The transfer_pair_id MUST be unique per transfer. An implementation that derives it from a longer-lived identifier, such as a lane identifier, relies entirely on ephemeral key freshness for key separation and SHOULD instead generate a random transfer_pair_id.
  • A chunk index MUST NOT be used twice under the same tunnel key. A transfer MUST NOT exceed 2^32 chunks.
  • The transfer_pair_id MUST be bound as associated data to every chunk, so that a chunk cannot be moved between transfers.

7.2. Chunk Topology and Final Summary

When a logical object is split into chunks, each chunk entry MUST identify the logical object it belongs to, its index, the total number of chunks, and a digest of the whole reassembled object. Before any chunk is released to the consumer, the receiver MUST verify that, for each logical object:

  • the set of indices is exactly 0 to total-1, with no gaps and no duplicates;
  • the declared total and the whole-object digest are identical across all chunks of that object;
  • the declared total is not zero.

The receiver MUST verify the reassembled object against the whole-object digest before the object becomes visible at its final location. A failed reassembly MUST NOT leave partial output in place. A receiver MAY verify incrementally, folding each chunk into a running digest, so that the whole object never needs to be held in memory at once.

Per-chunk integrity and the whole-object digest answer different questions: the first that each chunk is unaltered, the second that the right chunks were assembled in the right order. Both are REQUIRED before transfer_in is written.

8. Arrival and Admission

Arrival is not admission. A receiver or rendezvous point MAY accept sealed bytes without reading them, but before the content is opened or acted upon, the receiver MUST evaluate the following stages in order:

  1. Format: the carrier is recognized as a sealed carrier of a supported format and version.
  2. Integrity: the carrier's signatures and per-block or per-chunk integrity verify.
  3. Policy: the claimed sender identity resolves, is not revoked, and its registered verification key equals the key that signed the carrier; the intended receiver named in the carrier matches the receiver evaluating it.
  4. Trace: the outcome is recorded as a receipt, with a reference to the sender's transfer_out anchor when the carrier names one.

A failure at any stage MUST result in refusal. A refused carrier SHOULD be retained for forensic inspection, separate from accepted material. Retention of a refused carrier is a storage outcome; it MUST NOT be presented or interpreted as a pending review or as a hold on the sender.

An integrity check that holds establishes who produced the carrier and that its blocks belong to it. It does not establish that the producer key was current at the causal point of production. Implementations MUST NOT report a carrier as trusted on the strength of producer binding alone. A carrier that declares a producer binding which then fails MUST be treated as worse than a carrier that declares none, because the binding was meant to hold.

9. Carrier Change and Handoff Edges

A transfer, or the task it belongs to, may need to continue under a different carrier: a different device, actor, or runtime. The fact that a new carrier holds the same input bytes MUST NOT by itself be taken as evidence that it may continue. TAT separates three questions and evaluates them in order:

  1. Carrier change: did the carrier change, and does an edge declare that change? Outcomes are same, declared, and undeclared. An unnamed carrier on either side is undeclared, never same. An edge that names a different pair of actors than the observed change does not declare it.
  2. Edge validity: does the declaring edge hold? Outcomes are valid, invalid, and unprovable.
  3. Branch liveness: is the branch the edge departs from still live? Outcomes are same_epoch, declared_forward, stale_branch, dead_parent, and unknown.

A declared carrier change is not a valid one; it is a change that can now be judged. An undeclared carrier change MUST be treated as unknown continuity and MUST NOT be silently retried under the new carrier.

9.1. Handoff Edge Fields

A Handoff Edge MUST carry: from, to, task_root, carry_parent, predecessor_receipt_id, remaining_scope, nonce, freshness, and signature. An edge that omits any of these is unprovable. An empty remaining_scope is a valid declaration that nothing is handed on; only an absent field is undeclared.

An edge is invalid when any of the following holds:

  • its from and to do not match the observed carrier change;
  • its task_root differs from the task being carried (a handoff moves a carrier within a task; it does not move the task);
  • its carry_parent differs from the current carry;
  • its predecessor_receipt_id differs from the receipt the new carrier claims to continue;
  • remaining_scope contains anything the current carry did not hold, or the new carrier asks for anything remaining_scope does not contain;
  • its nonce has been spent before;
  • its signature does not verify.

An edge is unprovable when a required check cannot be performed, for example because no replay ledger or no verification key is available. Unprovable is never a pass.

The signature covers at least task_root, carry_parent, from, to, and nonce. Ed25519 [RFC8032] is RECOMMENDED.

9.2. Handoff Rules

  • Only a valid edge on a branch whose liveness is same_epoch or declared_forward MAY open a continuation under the new carrier. Neither invalid nor unprovable MAY degrade into continuation.
  • Opening a continuation is not admission. The new carrier MUST obtain a fresh admission before it acts; authority is not inherited across a carrier change.
  • A handoff MAY pass on or narrow the scope of the carry. It MUST NOT widen it.
  • Nonces MUST be claimed atomically: checking that a nonce is unused and recording it as spent MUST happen as one exclusive operation, and the record MUST survive process restarts. A replay ledger that cannot be read in full MUST be treated as unable to show that a nonce is unused.
  • A later stage MUST NOT rescue an earlier refusal. A valid edge does not revive a revoked or tombstoned parent.
  • Branch liveness is causal, not wall-clock. Silence does not age a branch; an intervening reseed, revocation, or fork does. A timeout MAY trigger a liveness check but MUST NOT be the liveness verdict. A parent that closed ungracefully is unknown until recovery evidence exists.

A carrier change is distinct from a change of transport lane. Moving the same carrier's bytes from one lane to another does not require a Handoff Edge; moving the transfer to a different carrier does.

10. Receipts

Every TAT decision step (consent, arrival, admission, and handoff) SHOULD produce a receipt, and a refusal MUST produce one whenever an acceptance at the same step would. A system that records only what it allowed cannot answer what it turned away.

A receipt MUST distinguish its own absence. Implementations MUST NOT encode the following three situations with the same value:

A refused receipt is not an absent receipt. When receipt production is refused, the implementation SHOULD record the refusing layer and its stated reason next to the empty receipt, and SHOULD attribute the refusal only as far as the reason supports, rather than to the nearest plausible layer. The underlying decision stands; consumers that require a verifiable receipt remain fail-closed.

A receipt SHOULD name the decider separately from the signer. The signer attests that it evaluated a specific input at a specific point; the decider is the evaluation that reached the outcome. A single field carrying both invites a signing key to be read as a source of authority. Inputs that the decider received but did not read SHOULD be listed as such.

Fields copied into a receipt from an unverified carrier MUST be marked as claimed, and a receipt for a refusal MUST NOT grant, restore, or promote anything.

11. Validation Rules

  1. Bilateral Consent: a sender MUST NOT begin protected content transfer before an explicit receiver-side consent has been verified. In store-and-forward mode, the receiver MUST NOT open or act on content before its own consent decision (Section 6).

  2. Seed Authenticity: the receiver MUST verify the seed signature, fingerprint, and transfer identifier before producing consent, and MUST check the sender verification key against the key registered for the claimed sender.

  3. Transfer-Pair Consistency: the same transfer_pair_id MUST appear in the initiating seed, the receiver consent, the sender transfer_out anchor, and the receiver transfer_in anchor.

  4. Stream Integrity: the receiver MUST verify the stream integrity, chunk topology, and final content summary before writing transfer_in (Section 7.2).

  5. Mutual Anchoring: the sender MUST write transfer_out before content flow, and the receiver MUST write transfer_in only after successful verification.

  6. Post-Transfer Finality: if a sender claims deactivation or succession, this MUST be represented by an explicit tombstone or equivalent finality object rather than by silent deletion alone.

  7. Arrival Is Not Admission: arrival and relay custody MUST NOT be treated as admission (Section 8).

  8. Carrier Change: a change of carrier MUST be declared by a valid Handoff Edge on a live branch, and the new carrier MUST be admitted fresh (Section 9).

  9. Fail-Closed Unknowns: a check that could not be performed MUST NOT be reported as a passed check.

12. Relationship to CEP, TIBET, SSM, ICC, and IDDrop

TAT is lower than IDDrop, complementary to SSM, orthogonal to ICC or TZA/TBZ sealed object semantics, and anchored by but not identical to TIBET causal truth.

CEP [CEP] is the umbrella continuity model, TAT is the generic handoff and transfer profile, and IDDrop [IDDROP] is an identity-transfer application profile over TAT.

A sealed carrier format answers whether its binding holds. The receiver answers whether the carrier may be admitted. TAT keeps these apart: a carrier format that refused on policy would impose one consumer's judgement on every other consumer.

13. Implementation Status

[RFC Editor: please remove this section, and the reference to RFC 7942, before publication.]

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.

According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

13.1. Humotica Reference Components

Organization
Humotica.
Description
Components of TAT exist across several Humotica code bases: the AInternet-in-a-Box appliance, a TBZ sealed-archive toolchain, and an arrival gate for a rendezvous inbox. They are not yet presented as one guarded TAT transfer flow; there is no single component that drives seed, consent, transfer_out, streaming, and transfer_in end to end as specified in Section 5. This is an open item.
Implemented
  • Tunnel key schedule of Section 7.1 (X25519, HKDF-SHA256 with transfer_pair_id as salt, an 8-octet nonce prefix followed by a 32-bit big-endian chunk index, AES-256-GCM).
  • A store-and-forward sealed offer: ephemeral-to-static X25519, a plaintext header signed with Ed25519 and bound to the sealed body by digest, and decryption failure for any key other than the intended receiver's. In this path the transfer_pair_id is derived from a lane identifier, which is the case Section 7.1 now discourages.
  • Chunk topology preflight and incremental whole-object verification with no partial output on failure (Section 7.2).
  • An arrival gate running format, integrity, policy, and trace stages, with registered-key binding of the sender, receiver match, revocation check, retention of refused carriers, and an arrival record that references the sender's transfer_out token as causal parent (Section 8).
  • Carrier change, Handoff Edge validity, and branch liveness as separate predicates, composed at a single call site that verifies signatures against a node key, claims nonces atomically in a durable ledger, writes a receipt for every outcome, and marks every opened continuation as still requiring fresh admission (Section 9).
  • Receipts that record a refused receipt production distinctly from an absent one, receipts that name signer and decider in separate fields, and append-only refusal receipts whose copied fields are marked as claimed (Section 10).
Not implemented
The interactive Consent Object exchange and interactive mode as one flow (an ephemeral-to-ephemeral derivation exists as a primitive, but no component drives the exchange around it); a tombstone written as part of a transfer; and a key-currentness check at the causal point of production.
Maturity
Development. Each component listed has its own tests; no interoperability testing with independent implementations has taken place.
Licensing
The TBZ toolchain is available under MIT or Apache-2.0. The AInternet-in-a-Box node is available under AGPL-3.0-or-later.
Contact
Jasper van de Meent, info@humotica.com.
Last updated
29 October 2026.

14. Security Considerations

TAT is designed to reduce ambiguity in sealed handoff, but several security properties depend on correct composition. Physical proximity alone is insufficient without explicit consent. Transport confidentiality is insufficient without mutual anchoring. Transfer success is insufficient without final integrity checks. Silent deletion is insufficient as proof of retirement.

Implementations SHOULD surface fingerprint, sender identity, or equivalent trust hints before consent. Implementations MUST treat transfer_pair_id reuse as suspicious. Replayed or stale consent responses MUST be rejected.

Key and nonce reuse. The key schedule in Section 7.1 is safe only if the pair of ephemeral key and transfer_pair_id never repeats and no chunk index repeats under one key. AES-GCM nonce reuse breaks both confidentiality and integrity.

Store-and-forward. Compromise of a receiver static key exposes every carrier sealed to it that an attacker has stored. Receivers SHOULD rotate static keys and SHOULD NOT reuse the static key as an identity signing key. Relays see header fields in clear; senders SHOULD keep those fields to what routing and recognition require.

Self-asserted keys. A verification key carried inside the object it verifies proves only internal consistency. Binding to a registered key for the claimed identity is what prevents sender spoofing.

Carrier change. Treating identical input bytes, or an unchecked edge, as permission for a new carrier is a privilege-inheritance path. The rules in Section 9.2 exist to close it. A durable, atomically claimed replay ledger is required because a replay that crosses a restart is still a replay.

Liveness. A signed and unreplayed edge can still point at a revoked or superseded parent. Liveness MUST be checked separately, and an unreadable revocation or epoch state MUST be treated as unknown, not as live.

Receipts as attack surface. Refusal receipts record content an attacker controls. Fields copied from an unverified carrier MUST NOT be executed, dereferenced, or used as lookup keys outside the receiver's own store.

Ambiguous absence. Collapsing "not required", "not attempted", and "refused" into one empty value causes operators to misread a correct refusal as a missing step, and to repair the wrong layer.

15. IANA Considerations

This document has no IANA actions.

16. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC5116]
McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, , <https://www.rfc-editor.org/info/rfc5116>.
[RFC5869]
Krawczyk, H. and P. Eronen, "HMAC-based Extract-and-Expand Key Derivation Function (HKDF)", RFC 5869, , <https://www.rfc-editor.org/info/rfc5869>.
[RFC7748]
Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, , <https://www.rfc-editor.org/info/rfc7748>.
[RFC8032]
Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital Signature Algorithm (EdDSA)", RFC 8032, , <https://www.rfc-editor.org/info/rfc8032>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8949]
Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, , <https://www.rfc-editor.org/info/rfc8949>.

17. Informative References

[RFC7942]
Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, , <https://www.rfc-editor.org/info/rfc7942>.
[CAUSAL]
van de Meent, J., "TIBET Causal Time", Work in Progress, Internet-Draft, draft-vandemeent-tibet-causal-time-02, , <https://datatracker.ietf.org/doc/html/draft-vandemeent-tibet-causal-time-02>.
[SSM]
van de Meent, J., "TIBET Semantic Surface Manifest", Work in Progress, Internet-Draft, draft-vandemeent-tibet-semantic-surface-manifest-02, , <https://datatracker.ietf.org/doc/html/draft-vandemeent-tibet-semantic-surface-manifest-02>.
[CEP]
van de Meent, J., "Continuity Envelope", Work in Progress, Internet-Draft, draft-vandemeent-continuity-envelope-00, , <https://datatracker.ietf.org/doc/html/draft-vandemeent-continuity-envelope-00>.
[IDDROP]
van de Meent, J., "IDDrop", Work in Progress, Internet-Draft, draft-vandemeent-iddrop-00, , <https://datatracker.ietf.org/doc/html/draft-vandemeent-iddrop-00>.

Changes from -00

Acknowledgments

The author thanks Root AI (Claude, Anthropic) and Codex for co-design of the handoff, arrival, and receipt rules in this revision, and for review of the reference components.

Author's Address

Jasper van de Meent
Humotica
Netherlands
URI: https://humotica.com/