The Collaboration Content Transfer (TCT) Protocol
draft-jurkovikj-collab-tunnel-03
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 | Antun Jurkovikj | ||
| Last updated | 2026-08-05 (Latest revision 2026-07-27) | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources |
Four-draft guided reconciliation story
Interactive TCT Draft-03 delivery-path demo Source for the browser-only protocol demos Standalone TCT Draft-03 validator WordPress Draft-03 experimental reference implementation |
||
| 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-jurkovikj-collab-tunnel-03
Network Working Group A. Jurkovikj
Internet-Draft 27 July 2026
Intended status: Experimental
Expires: 28 January 2027
The Collaboration Content Transfer (TCT) Protocol
draft-jurkovikj-collab-tunnel-03
Abstract
This document specifies the Collaboration Content Transfer (TCT)
Protocol, an experimental HTTP profile for efficient delivery of
publisher-selected web content to automated clients. TCT defines a
deterministic JSON representation at a machine-facing URL,
bidirectional discovery between human-facing and machine-facing
resources, JSON sitemaps containing representation-validator hints,
and conditional request behavior using ordinary strong ETags.
TCT preserves standard HTTP validator scope: an M-URL ETag identifies
the exact selected M-URL representation. Optional Semantic
Validators can correlate the logical state of human-facing and
machine-facing representations, but are not required by TCT and do
not replace ordinary cache validators. TCT does not define
authorization, licensing, content-use policy, or mutation semantics.
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 28 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jurkovikj Expires 28 January 2027 [Page 1]
Internet-Draft TCT July 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. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
3. TCT Profile Identifiers . . . . . . . . . . . . . . . . . . . 6
4. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. M-Sitemap Discovery . . . . . . . . . . . . . . . . . . . 6
4.2. C-URL to M-URL Discovery . . . . . . . . . . . . . . . . 7
4.3. M-URL to C-URL Discovery . . . . . . . . . . . . . . . . 7
4.4. URI Requirements . . . . . . . . . . . . . . . . . . . . 8
5. TCT M-URL Profile . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Response Requirements . . . . . . . . . . . . . . . . . . 8
5.2. JSON Envelope . . . . . . . . . . . . . . . . . . . . . . 9
5.3. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
5.4. Content Fidelity . . . . . . . . . . . . . . . . . . . . 10
5.5. Size and Segmentation . . . . . . . . . . . . . . . . . . 10
6. Deterministic JSON and TCT ETags . . . . . . . . . . . . . . 10
6.1. JCS Serialization . . . . . . . . . . . . . . . . . . . . 10
6.2. ETag Algorithm . . . . . . . . . . . . . . . . . . . . . 11
6.3. Content Codings . . . . . . . . . . . . . . . . . . . . . 11
6.4. Digest Fields . . . . . . . . . . . . . . . . . . . . . . 12
7. TCT M-Sitemap Profile . . . . . . . . . . . . . . . . . . . . 12
7.1. Response Requirements . . . . . . . . . . . . . . . . . . 12
7.2. JSON Structure . . . . . . . . . . . . . . . . . . . . . 13
7.3. ETag-Hint Consistency . . . . . . . . . . . . . . . . . . 14
7.4. Skip Optimization and Freshness . . . . . . . . . . . . . 14
8. TCT M-Sitemap Index Profile . . . . . . . . . . . . . . . . . 15
8.1. Response and Structure . . . . . . . . . . . . . . . . . 15
9. Client Processing . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Catalog Processing . . . . . . . . . . . . . . . . . . . 16
9.2. Constructing Conditional Requests from Catalog Hints . . 17
9.3. Conditional GET . . . . . . . . . . . . . . . . . . . . . 17
9.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.5. Failure Handling . . . . . . . . . . . . . . . . . . . . 17
10. Caching and Operational Considerations . . . . . . . . . . . 18
Jurkovikj Expires 28 January 2027 [Page 2]
Internet-Draft TCT July 2026
11. Relationship to Semantic Validators and AST . . . . . . . . . 18
12. Security Considerations . . . . . . . . . . . . . . . . . . . 19
12.1. Origin and Transport Authentication . . . . . . . . . . 19
12.2. Access Control and Catalog Leakage . . . . . . . . . . . 19
12.3. Cross-Origin and SSRF Risks . . . . . . . . . . . . . . 20
12.4. Untrusted Content and Agent Instructions . . . . . . . . 20
12.5. Content Divergence . . . . . . . . . . . . . . . . . . . 20
12.6. Cache Poisoning and Parser Differences . . . . . . . . . 20
12.7. Validator and Digest Limitations . . . . . . . . . . . . 20
12.8. Denial of Service . . . . . . . . . . . . . . . . . . . 21
13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 21
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
15. Changes Since -02 . . . . . . . . . . . . . . . . . . . . . . 21
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
16.1. Normative References . . . . . . . . . . . . . . . . . . 22
16.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Appendix A. Complete Discovery and Fetch Example . 24
A.1. Discover the Catalog . . . . . . . . . . . . . . . . . . 24
A.2. Retrieve the M-Sitemap . . . . . . . . . . . . . . . . . 24
A.3. Retrieve the M-URL . . . . . . . . . . . . . . . . . . . 25
A.4. Revalidate the M-URL . . . . . . . . . . . . . . . . . . 25
Appendix B. Appendix B. Catalog Skip Example . . . . . . . . . 25
Appendix C. Appendix C. Canonicalization and ETag Test
Vector . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix D. Acknowledgments . . . . . . . . . . . . . . . . . . 26
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
Automated clients such as search engines, archives, monitoring
systems, aggregators, retrieval systems, and AI-assisted tools often
need the substantive content of a web resource rather than its
complete browser presentation. Fetching and parsing full HTML pages
can repeatedly transfer templates, navigation, advertising, scripts,
and other material that is not needed for that task.
Many publishers already provide JSON APIs, feeds, Markdown views, or
crawler-specific endpoints. Those mechanisms differ in discovery,
envelope shape, canonical identity, and validator behavior. TCT
defines a narrow experimental profile that combines:
* a human-facing canonical URL (C-URL);
* a machine-facing deterministic JSON URL (M-URL);
* bidirectional Web links between those resources;
Jurkovikj Expires 28 January 2027 [Page 3]
Internet-Draft TCT July 2026
* an M-Sitemap listing C-URL/M-URL mappings and identity-
representation ETag hints; and
* normal HTTP conditional requests for target-resource validation.
The protocol is additive. Non-TCT clients ignore the additional
resources and links. TCT-aware clients can reduce repeated M-URL
transfers while retaining ordinary HTTP cache semantics.
The earlier name "Collaboration Tunnel" does not indicate network-
layer tunneling. It describes a publisher-provided content channel
alongside the human-facing web representation.
1.1. Conventions
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
*C-URL* The canonical human-facing URL of a participating resource,
commonly an HTML representation.
*M-URL* A machine-facing HTTP resource that provides the TCT JSON
representation of the content associated with a C-URL.
*M-Sitemap* A TCT JSON catalog containing C-URL/M-URL mappings and
optional validator hints.
*M-Sitemap Index* A TCT JSON document listing multiple M-Sitemaps.
*Identity representation* The selected M-URL, M-Sitemap, or
M-Sitemap Index representation served without a Content-Encoding
field. TCT catalog ETag hints refer to this representation.
*Authoritative validator* The ordinary HTTP ETag received from the
selected target representation. Catalog ETag members are hints
and do not replace the target's response metadata.
1.3. Goals
TCT is designed to:
* reuse HTTP methods, status codes, validators, caching, and Web
Linking;
Jurkovikj Expires 28 January 2027 [Page 4]
Internet-Draft TCT July 2026
* provide a compact publisher-generated text representation;
* make canonical identity and alternate-resource discovery explicit;
* make TCT JSON deterministic and reproducibly validated;
* permit catalog-level skip decisions with clearly bounded
freshness; and
* support incremental deployment and existing HTTP infrastructure.
1.4. Non-Goals
TCT does not:
* define whether content may be crawled, indexed, trained on,
summarized, or redistributed;
* replace authentication, authorization, robots rules, licensing, or
terms of service;
* define a prompt, instruction, tool-call, or agent-authority
format;
* define editing, synchronization, or cross-representation
concurrency;
* require a fixed M-URL or M-Sitemap path;
* define publisher analytics, receipts, policy descriptors, or
change feeds; or
* make ETags or digest fields authenticate publisher intent.
2. Protocol Overview
A typical flow is:
1. A client retrieves an origin resource and discovers an M-Sitemap
through a Link field or an HTML link element.
2. The client retrieves and validates the M-Sitemap profile and
structure.
3. For each item, the client learns the C-URL, M-URL, and optional
identity ETag hint.
Jurkovikj Expires 28 January 2027 [Page 5]
Internet-Draft TCT July 2026
4. The client retrieves an M-URL or conditionally revalidates a
cached representation with If-None-Match.
5. The M-URL links back to the C-URL with rel="canonical".
When a fresh or revalidated M-Sitemap contains an ETag hint equal to
a cached identity M-URL ETag, a client MAY reuse its cached M-URL
without another request. That reuse has freshness no stronger than
the M-Sitemap response and the publisher's catalog-update behavior.
A client requiring target-resource validation performs a conditional
request to the M-URL under normal HTTP cache semantics [RFC9111]. A
fresh intermediary can satisfy that request without contacting the
origin.
3. TCT Profile Identifiers
This revision defines three exact profile identifiers:
* M-URL profile: https://www.ietf.org/archive/id/draft-jurkovikj-
collab-tunnel-03.html#tct-m-url-profile
* M-Sitemap profile: https://www.ietf.org/archive/id/draft-
jurkovikj-collab-tunnel-03.html#tct-m-sitemap-profile
* M-Sitemap Index profile: https://www.ietf.org/archive/id/draft-
jurkovikj-collab-tunnel-03.html#tct-m-sitemap-index-profile
These identifiers refer to this exact Internet-Draft revision.
Clients MUST NOT treat a versionless Datatracker URI, another
revision, or a short string such as tct-1 as automatically
equivalent. A future RFC is expected to replace these identifiers
with stable RFC-based profile URIs.
4. Discovery
4.1. M-Sitemap Discovery
A TCT publisher MUST expose at least one M-Sitemap or M-Sitemap Index
and make it discoverable.
The preferred mechanism is an HTTP Link field [RFC8288] on a
successful response from the origin root or another documented entry
resource:
Link: </llm-sitemap.json>; rel="index"; type="application/json"
Jurkovikj Expires 28 January 2027 [Page 6]
Internet-Draft TCT July 2026
The registered index relation is generic. A client MUST NOT identify
the target as TCT solely from rel="index" and type="application/
json". It MUST retrieve the target and validate its top-level
profile, version, and required structure.
An HTML response MAY also advertise a candidate catalog:
<link rel="index" type="application/json" href="/llm-sitemap.json">
Clients SHOULD prefer the HTTP Link field when both mechanisms are
present. If an entry resource redirects, clients follow redirects
according to their normal HTTP policy and inspect the final response.
Clients MUST NOT guess well-known or conventional paths when
discovery is absent.
4.2. C-URL to M-URL Discovery
A participating C-URL SHOULD advertise the M-URL using
rel="alternate" and type="application/json":
Link: </article/123/llm.json>; rel="alternate"; type="application/json"
or, in HTML:
<link rel="alternate" type="application/json"
href="https://example.com/article/123/llm.json">
The alternate link does not by itself prove that the target is a TCT
M-URL. The client validates the target's profile and representation.
4.3. M-URL to C-URL Discovery
An M-URL response MUST contain a canonical link [RFC6596] to its
C-URL:
Link: <https://example.com/article/123>; rel="canonical"
It MUST also advertise the M-URL profile using the registered profile
relation [RFC6906]:
Link: <https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile>; rel="profile"
The JSON canonical_url member and the resolved canonical link target
SHOULD identify the same URI. A mismatch is a configuration or trust
signal; clients MAY reject the mapping.
Jurkovikj Expires 28 January 2027 [Page 7]
Internet-Draft TCT July 2026
4.4. URI Requirements
The canonical_url, cUrl, mUrl, and sitemap-index url values MUST be
absolute https or http URIs conforming to [RFC3986]. Publishers
SHOULD use HTTPS.
TCT catalogs SHOULD list same-origin M-URLs. A client following
cross-origin catalog entries or alternate links requires explicit
policy for redirects, SSRF, DNS rebinding, private-network
destinations, TLS identity, and credential forwarding. Validator
values are scoped to the origin and selected representation; equal
strings from different origins do not imply equal content.
5. TCT M-URL Profile
An M-URL is an ordinary HTTP resource serving a deterministic JSON
envelope. It is read-oriented; TCT does not define unsafe-method
behavior at an M-URL.
5.1. Response Requirements
An identity M-URL response:
* MUST use Content-Type: application/json;
* MUST be valid JSON [RFC8259];
* MUST be encoded as UTF-8 without a byte-order mark;
* MUST NOT include a charset parameter on application/json;
* MUST contain the profile and canonical links described above;
* MUST contain a strong ETag generated as specified below; and
* MUST send the exact JCS octets used to compute that ETag.
A server MUST provide the identity representation when the request
contains:
Accept-Encoding: identity
The server MAY provide content-coded variants to other requests, but
each non-identical selected representation requires its own strong
ETag and appropriate Vary: Accept-Encoding metadata.
Jurkovikj Expires 28 January 2027 [Page 8]
Internet-Draft TCT July 2026
5.2. JSON Envelope
The top-level JSON value MUST be an object with unique member names.
It MUST contain:
*profile* (string, REQUIRED) The exact M-URL profile URI defined by
this document.
*canonical_url* (string, REQUIRED) The absolute C-URL URI.
*title* (string, REQUIRED) A human-readable title for the resource.
*content* (string, REQUIRED) The publisher-selected substantive
content.
It MAY contain:
*language* (string, OPTIONAL) A well-formed BCP 47 language tag
[RFC5646] for the primary language of title and content. When
present, it SHOULD be consistent with Content-Language and the
C-URL's language metadata.
*content_media_type* (string, OPTIONAL) The media type describing
the string in content. When omitted, the value is text/plain;
charset=utf-8. Text-based values such as text/plain and text/
markdown [RFC7763] are expected. A producer MUST NOT claim a
media type whose syntax the content string does not follow.
Example before canonical serialization:
{
"profile": "https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile",
"canonical_url": "https://example.com/article/123",
"title": "Understanding HTTP Validators",
"language": "en",
"content_media_type": "text/markdown; charset=utf-8",
"content": "# Overview\n\nHTTP validators support efficient revalidation."
}
5.3. Extensibility
Producers MAY add members. Clients MUST ignore unknown members
unless an applicable extension profile says otherwise. Unknown
members remain part of the JSON value and therefore are included in
JCS serialization and ETag calculation.
Jurkovikj Expires 28 January 2027 [Page 9]
Internet-Draft TCT July 2026
Duplicate object member names are invalid for TCT. A client MUST
reject a TCT document containing duplicates rather than relying on
parser-specific selection. Producers and clients MUST satisfy the
input constraints of JCS [RFC8785], including deterministic handling
of numbers and strings.
A client that does not recognize the exact profile value MUST NOT
process the document as conforming to this revision merely because
its shape appears similar.
5.4. Content Fidelity
TCT does not define case folding, Unicode compatibility
normalization, whitespace collapse, HTML entity decoding, or Markdown
rewriting. A producer MUST treat the final title, content, and other
string values as the representation to be delivered and validated.
A publisher can extract, summarize, convert, or normalize upstream
source when constructing an M-URL, but the resulting transformation
is part of the publisher-selected representation and SHOULD be
documented when it materially affects fidelity. TCT itself does not
claim that the M-URL is lossless.
This rule avoids corrupting case-sensitive URLs, source code,
identifiers, quoted language, Markdown code blocks, or whitespace-
sensitive content.
5.5. Size and Segmentation
Publishers SHOULD avoid unbounded content values. Large works can be
split into stable logical resources such as chapters or sections.
Clients MAY impose response-size, nesting, member-count, and string-
length limits and MAY skip or defer resources exceeding those limits.
6. Deterministic JSON and TCT ETags
All identity TCT JSON representations -- M-URLs, M-Sitemaps, and
M-Sitemap Indexes -- use the same JCS and SHA-256 ETag algorithm in
this section.
6.1. JCS Serialization
The producer MUST serialize the complete JSON value using JSON
Canonicalization Scheme (JCS) [RFC8785]. The exact JCS UTF-8 octet
sequence MUST be:
* the response content of the identity representation; and
Jurkovikj Expires 28 January 2027 [Page 10]
Internet-Draft TCT July 2026
* the input to the ETag algorithm.
The producer MUST NOT add insignificant whitespace, vary member
ordering, insert per-request timestamps, or otherwise change the
identity response bytes without changing the ETag.
6.2. ETag Algorithm
For an identity TCT JSON representation:
1. Construct the complete JSON value.
2. Serialize it to JCS UTF-8 octets.
3. Compute SHA-256 [RFC6234] over those octets.
4. Encode the digest as 64 lowercase hexadecimal characters.
5. Set the ETag field value to a quoted opaque tag of the form
"sha256-<64-lowercase-hex-digits>".
The ETag MUST be strong and MUST NOT use the W/ prefix.
Two successful identity responses with the same strong ETag MUST have
identical content octets. Any change to those octets MUST change the
ETag. Clients treat the ETag as opaque; they are not required to
recompute the hash.
Example:
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "sha256-0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef"
Vary: Accept-Encoding
Link: <https://example.com/article/123>; rel="canonical"
Link: <https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile>; rel="profile"
6.3. Content Codings
A content-coded TCT representation is a different selected
representation when its representation data differ. Its strong ETag
MUST differ from the identity ETag. A server MUST NOT reuse the
identity strong ETag for gzip, Brotli, or another non-identical coded
variant.
Jurkovikj Expires 28 January 2027 [Page 11]
Internet-Draft TCT July 2026
The etag member in an M-Sitemap always refers to the identity M-URL
ETag. A client using that value in If-None-Match MUST also request
Accept-Encoding: identity. The same rule applies to an M-Sitemap
Index validator hint for a subordinate M-Sitemap.
6.4. Digest Fields
For an identity representation, a server SHOULD include Content-
Digest with sha-256 according to [RFC9530]. Digest Fields provide
content-integrity metadata; they do not authenticate the server,
publisher intent, or semantic equivalence.
When a content coding is selected, the server follows the digest and
representation rules of [RFC9530]. TCT does not redefine those
rules.
7. TCT M-Sitemap Profile
An M-Sitemap is a JSON catalog of TCT resources.
7.1. Response Requirements
An identity M-Sitemap response:
* MUST use Content-Type: application/json without a charset
parameter;
* MUST use UTF-8 without a byte-order mark;
* MUST be valid JCS JSON with unique member names;
* MUST advertise the M-Sitemap profile using rel="profile";
* MUST have its own strong HTTP ETag generated by the TCT ETag
algorithm;
* MUST support If-None-Match; and
* SHOULD use cache directives appropriate to the publisher's update
frequency.
The M-Sitemap's own ETag validates the M-Sitemap representation. It
is independent of the item-level M-URL ETags carried inside the
catalog.
Jurkovikj Expires 28 January 2027 [Page 12]
Internet-Draft TCT July 2026
7.2. JSON Structure
The top-level object MUST contain:
*version* (integer, REQUIRED) The value 2 for this M-Sitemap format.
*profile* (string, REQUIRED) The exact M-Sitemap profile URI defined
by this document.
*items* (array, REQUIRED) The complete item set represented by this
M-Sitemap.
Each item MUST be an object containing:
*cUrl* (string, REQUIRED) The absolute C-URL.
*mUrl* (string, REQUIRED) The absolute M-URL.
Each item MAY contain:
*etag* (string, OPTIONAL) The ASCII string sha256- followed by
exactly 64 lowercase hexadecimal digits, copied from the current
identity M-URL ETag after removing the surrounding HTTP DQUOTE
characters. For example, HTTP ETag:
"sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
is represented as the JSON string
"sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b".
Any other length, prefix, character, hexadecimal case, weak
validator, or digest algorithm is invalid as a TCT catalog hint.
A producer MUST NOT emit such a value.
*lastModified* (string, OPTIONAL) An RFC 3339 timestamp [RFC3339]
supplied as scheduling metadata. It is not an HTTP validator and
does not replace ETag revalidation.
Example before JCS serialization:
Jurkovikj Expires 28 January 2027 [Page 13]
Internet-Draft TCT July 2026
{
"version": 2,
"profile": "https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-profile",
"items": [
{
"cUrl": "https://example.com/article/123",
"mUrl": "https://example.com/article/123/llm.json",
"etag": "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b",
"lastModified": "2026-07-15T09:00:00Z"
}
]
}
Unknown members are permitted and ignored by clients, but remain part
of the catalog representation and its own ETag. A client MUST reject
duplicate member names or an unrecognized profile.
7.3. ETag-Hint Consistency
At the time an origin generates an M-Sitemap representation, each
included etag value MUST equal the current identity M-URL ETag for
the corresponding mUrl. If the publisher cannot obtain a consistent
value, it MUST omit the member rather than knowingly publish a
different validator.
Publishers SHOULD generate the catalog from a consistent snapshot and
SHOULD update catalogs promptly when M-URL identity representations
change. Ordinary HTTP caching and distributed publication can still
cause a client to observe an older, but valid, M-Sitemap response.
The item etag is advisory. The authoritative validator is the ETag
received from the M-URL response selected by the client's request. A
mismatch does not make the M-URL response invalid; the client uses
the response ETag and can treat the catalog as stale or inconsistent.
7.4. Skip Optimization and Freshness
A client that has cached the identity M-URL representation can
compare its cached ETag's opaque value with the M-Sitemap etag value.
When they are equal, the client MAY skip an M-URL request and reuse
the cached representation. By doing so, the client accepts freshness
bounded by:
* the freshness or successful revalidation of the M-Sitemap
response;
Jurkovikj Expires 28 January 2027 [Page 14]
Internet-Draft TCT July 2026
* any origin publication delay between M-URL and catalog updates;
and
* normal races occurring after the M-Sitemap response was generated.
The comparison does not prove that the M-URL remains current at a
later instant. A client requiring target-resource validation MUST
issue a conditional request to the M-URL. Under normal cache
semantics, a fresh intermediary can satisfy that request without
contacting the origin. A client that requires successful origin
validation SHOULD also send the Cache-Control request field with no-
cache as defined by [RFC9111].
When the values differ, or the item omits etag, the client SHOULD
issue a conditional M-URL request using its cached M-URL ETag.
8. TCT M-Sitemap Index Profile
Large origins MAY divide the catalog into multiple M-Sitemaps and
advertise an M-Sitemap Index.
8.1. Response and Structure
An identity M-Sitemap Index follows the same JSON, JCS, content-type,
own-ETag, and If-None-Match requirements as an M-Sitemap. It
advertises the M-Sitemap Index profile with rel="profile".
Its top-level object MUST contain:
*version* (integer, REQUIRED) The value 1.
*profile* (string, REQUIRED) The exact M-Sitemap Index profile URI
defined by this document.
*sitemaps* (array, REQUIRED) The complete set of subordinate
M-Sitemaps represented by the index.
Each entry MUST contain:
*url* (string, REQUIRED) The absolute M-Sitemap URI.
It MAY contain:
*etag* (string, OPTIONAL) The value, without HTTP quotes, of the
subordinate M-Sitemap's current identity-representation ETag at
index generation time. It MUST use the same sha256- plus 64
lowercase hexadecimal digit syntax and consistency rules as an
M-Sitemap item ETag.
Jurkovikj Expires 28 January 2027 [Page 15]
Internet-Draft TCT July 2026
Example:
{
"version": 1,
"profile": "https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-index-profile",
"sitemaps": [
{
"url": "https://example.com/sitemaps/part-1.json",
"etag": "sha256-ae4dbbda6e78704448531138f1574e348b0a361c10ed545af54e1bc8278f8168"
},
{
"url": "https://example.com/sitemaps/part-2.json"
}
]
}
An index MUST NOT contain a top-level items member. An M-Sitemap
MUST NOT contain a top-level sitemaps member.
Indexes MUST NOT recursively identify other indexes. Clients SHOULD
detect and stop cycles and SHOULD enforce catalog-count and depth
limits.
9. Client Processing
9.1. Catalog Processing
A client:
1. discovers a candidate M-Sitemap or Index;
2. retrieves it using normal HTTP caching and conditional requests;
3. verifies Content-Type, JSON validity, unique names, profile,
version, and required structure;
4. resolves only URIs permitted by its origin and security policy;
and
5. processes entries subject to local size, rate, and content
policies.
A client MUST NOT use an ETag hint from one origin as a validator at
another origin.
Jurkovikj Expires 28 January 2027 [Page 16]
Internet-Draft TCT July 2026
9.2. Constructing Conditional Requests from Catalog Hints
Because catalog etag values omit HTTP quotes, a client using one in
If-None-Match adds the required DQUOTE characters and requests the
identity representation:
GET /article/123/llm.json HTTP/1.1
Host: example.com
Accept-Encoding: identity
If-None-Match: "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
A client MUST validate that the catalog value is sha256- followed by
exactly 64 lowercase hexadecimal digits before constructing the
field. It MUST NOT construct a conditional field from any other
value and MUST NOT add a W/ prefix. It MAY treat an invalid etag
member as absent and fetch the target normally, or reject the
containing item or catalog according to local policy.
If the M-URL returns 200 OK with a different ETag, the client stores
the response content and authoritative response ETag. If it returns
304 Not Modified, the client reuses the stored identity
representation according to HTTP caching rules.
9.3. Conditional GET
M-URLs MUST process If-None-Match according to [RFC9110]. A matching
condition on GET or HEAD produces 304 Not Modified; a nonmatching
condition produces the normal selected representation, commonly 200
OK.
When a corresponding 200 response would contain ETag, the 304
response MUST include the current ETag as required by HTTP.
If both If-None-Match and If-Modified-Since are present, If-None-
Match takes precedence under [RFC9110].
9.4. HEAD
Servers SHOULD support HEAD on M-URLs and catalogs when they can
return metadata consistent with GET. Conditional GET remains the
primary and most reliable mechanism because some deployments generate
incomplete or inconsistent HEAD metadata.
9.5. Failure Handling
If a catalog is unavailable, invalid, too large, or unrecognized, the
client SHOULD treat TCT as unavailable for that discovery path. It
MAY use the C-URL or another publisher-provided mechanism.
Jurkovikj Expires 28 January 2027 [Page 17]
Internet-Draft TCT July 2026
Clients process 4xx and 5xx responses according to HTTP. They SHOULD
honor Retry-After, apply exponential or comparable backoff after 429
Too Many Requests and 503 Service Unavailable, and obey cache
freshness rather than a fixed polling interval.
10. Caching and Operational Considerations
M-URLs, M-Sitemaps, and M-Sitemap Indexes are ordinary cacheable
resources governed by [RFC9111]. Publishers select Cache-Control
according to update frequency and sensitivity. Catalogs SHOULD have
short enough freshness lifetimes to make their hints useful, while
avoiding unnecessary revalidation.
A shared cache or CDN:
* MUST preserve correct ETag semantics for each selected
representation;
* MUST NOT reuse a strong ETag across non-identical coded and
identity representations;
* MUST honor Vary: Accept-Encoding when coding selection depends on
that field; and
* MUST NOT rewrite TCT JSON without generating the corresponding new
validator.
Publishers SHOULD give M-Sitemaps and indexes their own strong ETags
so clients can revalidate large catalogs without retransferring them.
TCT does not require atomic publication across several HTTP
resources. A client can observe a catalog snapshot concurrent with
resource updates. The bounded skip semantics above and M-URL
validation under normal HTTP cache semantics provide the fallback
behavior.
11. Relationship to Semantic Validators and AST
TCT defines read-oriented representations and ordinary representation
validators. It does not define cross-representation concurrency.
An origin implementing Semantic Validators for HTTP
[I-D.jurkovikj-http-semantic-validator] MAY include the same
Semantic-ETag on a C-URL and M-URL when both belong to the same
semantic equivalence domain:
Jurkovikj Expires 28 January 2027 [Page 18]
Internet-Draft TCT July 2026
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
Semantic-ETag: "article-state-v7"
The fields remain independent:
* ETag changes whenever the exact selected M-URL representation
changes.
* Semantic-ETag changes whenever the shared logical state changes
under the origin-defined domain.
A TCT M-URL is not an AST State-Bearing Representation merely because
it is JSON, deterministic, or machine-oriented. It becomes an AST
SBR only when it losslessly exposes the complete Canonical Resource
State, is explicitly advertised as an AST SBR, and implements the
applicable AST requirements [I-D.jurkovikj-httpapi-agentic-state].
TCT clients MUST NOT send If-Semantic-Match merely because a response
carries Semantic-ETag; positive capability knowledge is required by
the Semantic Validator specification.
12. Security Considerations
12.1. Origin and Transport Authentication
Publishers SHOULD use HTTPS, and clients SHOULD validate TLS
identities and redirect destinations. Strong ETags and Digest Fields
do not authenticate the server or publisher intent. Applications
needing message authentication can use HTTP Message Signatures
[RFC9421] or another appropriate mechanism.
12.2. Access Control and Catalog Leakage
If a C-URL requires authorization, the corresponding M-URL SHOULD
provide at least equivalent protection. Public M-Sitemaps MUST NOT
reveal sensitive, unlisted, tenant-specific, or authorization-scoped
resource URLs or validator information.
Robots rules communicate crawler preferences; they are not access-
control mechanisms. Sensitive resources require authentication and
authorization even when robots rules also apply.
Jurkovikj Expires 28 January 2027 [Page 19]
Internet-Draft TCT July 2026
12.3. Cross-Origin and SSRF Risks
Catalogs and links contain attacker-controlled URIs from the client's
perspective. Clients need explicit policy for allowed schemes,
origins, ports, redirects, DNS changes, private and link-local
networks, and credential forwarding. Credentials MUST NOT be
forwarded to a newly discovered authority solely because it appears
in a TCT document or link.
12.4. Untrusted Content and Agent Instructions
Clients MUST treat all envelope members, especially content, as
untrusted publisher-supplied data. TCT content is not trusted
policy, authorization, tool instructions, or an override of local
client controls.
AI-assisted clients SHOULD apply prompt-injection defenses, evidence
gating, tool-use authorization, and local policy before acting on
statements contained in TCT content.
12.5. Content Divergence
An origin can publish an M-URL that differs materially from its
C-URL. TCT links and validators establish representation identity
and change detection, not substantive equivalence or honesty.
Clients MAY sample both resources and use persistent unexplained
divergence as a trust signal.
12.6. Cache Poisoning and Parser Differences
Clients must validate JSON structure, unique member names, profiles,
sizes, and URIs before use. JCS input restrictions and exact
profiles reduce parser ambiguity, but do not make content trusted.
Caches and proxies that rewrite content without correcting validators
can cause stale or mixed responses.
12.7. Validator and Digest Limitations
SHA-256 collision resistance supports representation validation, but
an ETag is not a secret, authorization token, signature, or proof of
semantic equivalence. Digest Fields detect content alteration
according to their specification but do not identify an authorized
publisher without an authenticated channel or signature.
Jurkovikj Expires 28 January 2027 [Page 20]
Internet-Draft TCT July 2026
12.8. Denial of Service
Large catalogs, deeply nested JSON, long strings, redirect chains,
and a large number of M-URLs can consume client resources. Clients
SHOULD impose limits, process catalogs incrementally where practical,
rate-limit retrieval, and stop cycles.
13. Privacy Considerations
M-Sitemaps can reveal site structure, update cadence, language
variants, and content identifiers. Publishers SHOULD omit sensitive
resources and protect private catalogs. Clients SHOULD minimize
unnecessary request identifiers and follow applicable privacy policy.
14. IANA Considerations
This document requests no new IANA registrations. It uses registered
HTTP fields and link relations and identifies this experimental
revision with exact URI-valued profiles.
A future standards-track version can request dedicated media types, a
well-known discovery URI, or other registrations if implementation
experience shows that they improve interoperability.
15. Changes Since -02
This revision:
* restores all main section and subsection headings;
* replaces short, ambiguous profile strings with exact URI-valued
profiles;
* removes the undefined profile Link target attribute from
discovery;
* removes charset from application/json response examples;
* adds URI, BCP 47, duplicate-name, unknown-member, and size-
processing rules;
* removes the optional Unicode case-folding and whitespace-
normalization profiles from TCT core;
* requires the served identity body to be the same JCS bytes used
for ETag generation;
Jurkovikj Expires 28 January 2027 [Page 21]
Internet-Draft TCT July 2026
* defines catalog ETag hints as identity-representation validators
and requires Accept-Encoding: identity when clients use them
conditionally;
* requires every catalog ETag hint to use the exact TCT SHA-256 ETag
form;
* gives M-Sitemaps and indexes their own ETags and conditional-
request behavior;
* narrows "zero-fetch" to a skip optimization with catalog-bounded
freshness and distinguishes cache validation from successful
origin validation;
* removes the fixed one-minute refetch rule in favor of HTTP
freshness, Retry-After, and backoff;
* clarifies that robots rules are not access control;
* adds cross-origin and SSRF requirements; and
* clarifies optional Semantic Validator correlation and the rule
that an M-URL is not an AST SBR by default.
16. References
16.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", STD 98, RFC 9111,
DOI 10.17487/RFC9111, June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
Jurkovikj Expires 28 January 2027 [Page 22]
Internet-Draft TCT July 2026
[RFC6596] Ohye, M. and J. Kupke, "The Canonical Link Relation",
RFC 6596, DOI 10.17487/RFC6596, April 2012,
<https://www.rfc-editor.org/rfc/rfc6596>.
[RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
DOI 10.17487/RFC6906, March 2013,
<https://www.rfc-editor.org/rfc/rfc6906>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/rfc/rfc5646>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", RFC 8785,
DOI 10.17487/RFC8785, June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and SHA-based HMAC and HKDF)", RFC 6234,
DOI 10.17487/RFC6234, May 2011,
<https://www.rfc-editor.org/rfc/rfc6234>.
[RFC9530] Polli, R. and L. Pardue, "Digest Fields", RFC 9530,
DOI 10.17487/RFC9530, February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
16.2. Informative References
Jurkovikj Expires 28 January 2027 [Page 23]
Internet-Draft TCT July 2026
[RFC7763] Leonard, S., "The text/markdown Media Type", RFC 7763,
DOI 10.17487/RFC7763, March 2016,
<https://www.rfc-editor.org/rfc/rfc7763>.
[I-D.jurkovikj-http-semantic-validator]
Jurkovikj, A., "Semantic Validators for HTTP", Work in
Progress, Internet-Draft, draft-jurkovikj-http-semantic-
validator-01, 27 July 2026,
<https://datatracker.ietf.org/doc/html/draft-jurkovikj-
http-semantic-validator-01>.
[I-D.jurkovikj-httpapi-agentic-state]
Jurkovikj, A., "HTTP Profile for Conditional Updates to
Shared Resource State (Agentic State Transfer)", Work in
Progress, Internet-Draft, draft-jurkovikj-httpapi-agentic-
state-02, 27 July 2026,
<https://datatracker.ietf.org/doc/html/draft-jurkovikj-
httpapi-agentic-state-02>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
Appendix A. Appendix A. Complete Discovery and Fetch Example
A.1. Discover the Catalog
GET / HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: text/html
Link: </llm-sitemap.json>; rel="index"; type="application/json"
A.2. Retrieve the M-Sitemap
The following body is the exact JCS serialization of the displayed
value. Its SHA-256 ETag was calculated over those UTF-8 octets.
Jurkovikj Expires 28 January 2027 [Page 24]
Internet-Draft TCT July 2026
GET /llm-sitemap.json HTTP/1.1
Host: example.com
Accept-Encoding: identity
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "sha256-ae4dbbda6e78704448531138f1574e348b0a361c10ed545af54e1bc8278f8168"
Cache-Control: max-age=300, must-revalidate
Link: <https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-profile>; rel="profile"
{"items":[{"cUrl":"https://example.com/article/123","etag":"sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b","mUrl":"https://example.com/article/123/llm.json"}],"profile":"https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-profile","version":2}
A.3. Retrieve the M-URL
The following body is the exact JCS serialization of the displayed
value. Its SHA-256 ETag was calculated over those UTF-8 octets.
GET /article/123/llm.json HTTP/1.1
Host: example.com
Accept-Encoding: identity
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
Link: <https://example.com/article/123>; rel="canonical"
Link: <https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile>; rel="profile"
{"canonical_url":"https://example.com/article/123","content":"# Overview\n\nExample content.","content_media_type":"text/markdown; charset=utf-8","profile":"https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile","title":"Example"}
A.4. Revalidate the M-URL
GET /article/123/llm.json HTTP/1.1
Host: example.com
Accept-Encoding: identity
If-None-Match: "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
HTTP/1.1 304 Not Modified
ETag: "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b"
Appendix B. Appendix B. Catalog Skip Example
A client has cached the identity M-URL with ETag
"sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b".
It retrieves or successfully revalidates the M-Sitemap and observes
the equal item etag value without HTTP quotes.
The client can either:
Jurkovikj Expires 28 January 2027 [Page 25]
Internet-Draft TCT July 2026
* skip the M-URL request and accept freshness bounded by the
M-Sitemap and publication behavior; or
* issue the conditional M-URL request above when target-resource
validation is required, adding Cache-Control: no-cache to request
successful origin validation.
The skip decision is an optimization, not a stronger freshness
guarantee than HTTP provides for the M-Sitemap response.
Appendix C. Appendix C. Canonicalization and ETag Test Vector
Input JSON value:
{
"profile": "https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile",
"canonical_url": "https://example.com/post/",
"title": "Example",
"content": "Hello"
}
Exact JCS UTF-8 text:
{"canonical_url":"https://example.com/post/","content":"Hello","profile":"https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile","title":"Example"}
SHA-256 hexadecimal:
d5a54a6e2a2ee0f0b84592d4d6c9f5361aeea41e4cb23550f4804e3ea29eaa2c
Resulting ETag:
"sha256-d5a54a6e2a2ee0f0b84592d4d6c9f5361aeea41e4cb23550f4804e3ea29eaa2c"
Appendix D. Acknowledgments
Thanks to reviewers and implementers who identified the need to
preserve ordinary HTTP validator scope, separate semantic state from
representation identity, define catalog-bounded skip semantics, and
simplify the experimental protocol surface.
Author's Address
Antun Jurkovikj
North Macedonia
Email: antunjurkovic@gmail.com
Jurkovikj Expires 28 January 2027 [Page 26]