The Collaboration Tunnel Protocol
draft-jurkovikj-collab-tunnel-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.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Antun Jurkovikj | ||
| Last updated | 2025-11-04 | ||
| RFC stream | (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-jurkovikj-collab-tunnel-00
Network Working Group A. Jurkovikj
Internet-Draft 4 November 2025
Intended status: Standards Track
Expires: 8 May 2026
The Collaboration Tunnel Protocol
draft-jurkovikj-collab-tunnel-00
Abstract
This document specifies the Collaboration Tunnel Protocol, a method
for efficient, verifiable content delivery between web publishers and
automated agents. The protocol typically achieves up to 90%
bandwidth reduction (83% median measured) through bidirectional URL
discovery, template-invariant content fingerprinting, sitemap-first
verification, and strict conditional request discipline.
Test Vector 2: Entity and Unicode - Input String (literal): Test
& Unicode: café- - Normalized String: test & unicode: café- -
SHA-256 (hex):
f58639b586fac9cb70d4513c83a6b2954178a80f12f5c1069aad09d124ef7b24 -
contentHash: sha256-
f58639b586fac9cb70d4513c83a6b2954178a80f12f5c1069aad09d124ef7b24 -
ETag: "sha256-
f58639b586fac9cb70d4513c83a6b2954178a80f12f5c1069aad09d124ef7b24"
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 8 May 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Jurkovikj Expires 8 May 2026 [Page 1]
Internet-Draft Collab-Tunnel November 2025
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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Requirements . . . . . . . . . . . . . . . . . . . . 6
3.1. MUST Requirements . . . . . . . . . . . . . . . . . . . . 6
3.2. SHOULD Recommendations . . . . . . . . . . . . . . . . . 9
3.3. MAY Extensions . . . . . . . . . . . . . . . . . . . . . 9
4. Bidirectional Discovery . . . . . . . . . . . . . . . . . . . 10
4.1. C-URL to M-URL Mapping . . . . . . . . . . . . . . . . . 10
4.2. M-URL to C-URL Canonicalization . . . . . . . . . . . . . 10
4.3. Deterministic Mapping . . . . . . . . . . . . . . . . . . 11
4.4. Content Pages Only . . . . . . . . . . . . . . . . . . . 11
5. Template-Invariant Fingerprinting . . . . . . . . . . . . . . 12
5.1. Publisher Source of Content (Informative) . . . . . . . . 13
5.2. Normalization Algorithm . . . . . . . . . . . . . . . . . 14
5.3. Deterministic JSON Serialization (Normative) . . . . . . 15
5.4. Strong ETag and Parity (Normative) . . . . . . . . . . . 16
5.4.1. Method A: Canonical JSON Strong-Byte (Recommended) . 16
5.4.2. Method B: Content-Locked Strong-Content (Allowed with
Restrictions) . . . . . . . . . . . . . . . . . . . . 18
5.5. Parity Rule (Normative) . . . . . . . . . . . . . . . . . 19
5.6. Template-Invariance . . . . . . . . . . . . . . . . . . . 19
6. Conditional Request Discipline . . . . . . . . . . . . . . . 20
6.1. If-None-Match Precedence . . . . . . . . . . . . . . . . 20
6.2. 304 Not Modified Response . . . . . . . . . . . . . . . . 20
6.3. Replay and Stale Intermediaries . . . . . . . . . . . . . 21
6.4. Cache-Control Directives . . . . . . . . . . . . . . . . 21
6.5. Vary Header . . . . . . . . . . . . . . . . . . . . . . . 21
6.6. HEAD Request Support . . . . . . . . . . . . . . . . . . 22
7. Sitemap-First Verification . . . . . . . . . . . . . . . . . 22
7.1. JSON Sitemap Format . . . . . . . . . . . . . . . . . . . 22
7.2. Sitemap Scalability . . . . . . . . . . . . . . . . . . . 24
7.3. Error Handling (Informative) . . . . . . . . . . . . . . 26
7.4. Zero-Fetch Skip Logic . . . . . . . . . . . . . . . . . . 26
8. Publisher Policy Descriptor . . . . . . . . . . . . . . . . . 27
Jurkovikj Expires 8 May 2026 [Page 2]
Internet-Draft Collab-Tunnel November 2025
8.1. Policy Endpoint . . . . . . . . . . . . . . . . . . . . . 27
8.2. JSON Schema . . . . . . . . . . . . . . . . . . . . . . . 27
8.3. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 29
8.4. Alignment with IETF AIPREF . . . . . . . . . . . . . . . 30
9. M-URL Response Format . . . . . . . . . . . . . . . . . . . . 30
9.1. Content-Type . . . . . . . . . . . . . . . . . . . . . . 30
9.2. JSON Payload Schema . . . . . . . . . . . . . . . . . . . 30
9.3. Complete Response Example . . . . . . . . . . . . . . . . 31
10. Operational Considerations (Informative) . . . . . . . . . . 32
11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
11.1. HTTPS and TLS . . . . . . . . . . . . . . . . . . . . . 33
11.2. Rate Limiting . . . . . . . . . . . . . . . . . . . . . 33
11.3. Content Integrity . . . . . . . . . . . . . . . . . . . 33
11.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . 33
11.5. Denial of Service . . . . . . . . . . . . . . . . . . . 34
11.5.1. Sitemap Abuse . . . . . . . . . . . . . . . . . . . 34
11.5.2. HEAD vs GET Bandwidth . . . . . . . . . . . . . . . 34
11.6. Injection Surface Reduction . . . . . . . . . . . . . . 34
11.7. Cache Poisoning . . . . . . . . . . . . . . . . . . . . 34
11.8. Fingerprint Collision and Normalization Variance . . . . 34
11.9. Content Provenance and Origin Authentication
(Optional) . . . . . . . . . . . . . . . . . . . . . . 34
11.10. Privacy and PII . . . . . . . . . . . . . . . . . . . . 35
11.11. Access Control . . . . . . . . . . . . . . . . . . . . . 35
12. Energy Efficiency Considerations . . . . . . . . . . . . . . 36
12.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 36
12.2. Network Energy Consumption . . . . . . . . . . . . . . . 36
12.3. AI Inference Impact (Informative Summary) . . . . . . . 36
12.4. Sitemap-First Zero-Fetch Optimization . . . . . . . . . 37
12.5. Comparison to Existing Approaches . . . . . . . . . . . 37
12.6. Cumulative Environmental Impact . . . . . . . . . . . . 37
12.7. Relationship to IETF GREEN Working Group . . . . . . . . 38
12.8. Recommendations for Implementers . . . . . . . . . . . . 38
12.9. Future Work . . . . . . . . . . . . . . . . . . . . . . 39
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
14. Comparison to Prior Art . . . . . . . . . . . . . . . . . . . 39
14.1. ResourceSync . . . . . . . . . . . . . . . . . . . . . . 40
14.2. AMP . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.3. XML Sitemaps . . . . . . . . . . . . . . . . . . . . . . 40
15. Implementation Status . . . . . . . . . . . . . . . . . . . . 41
16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
17.1. Normative References . . . . . . . . . . . . . . . . . . 42
17.2. Informative References . . . . . . . . . . . . . . . . . 42
Appendix A. Example Implementation (WordPress) . . . . . . . . . 44
Appendix B. Example Sitemap . . . . . . . . . . . . . . . . . . 45
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 46
Jurkovikj Expires 8 May 2026 [Page 3]
Internet-Draft Collab-Tunnel November 2025
1. Introduction
Automated agents (AI crawlers, search engines, content aggregators)
increasingly consume web content at scale. Traditional HTML delivery
designed for human browsers imposes unnecessary overhead:
presentational boilerplate (navigation, footers, advertisements),
large CSS/JavaScript bundles, and redundant fetches of unchanged
content.
Existing approaches address portions of this problem:
* XML Sitemaps [XMLSitemaps] provide discovery but lack content
fingerprints
* AMP [AMP] reduces HTML overhead but lacks synchronized hashing
* ResourceSync [ResourceSync] provides digest-based synchronization
but lacks endpoint-level validator discipline
The Collaboration Tunnel Protocol (TCT, also referred to as "collab-
tunnel") integrates these concepts into a cohesive system optimized
for machine consumption while preserving human-readable canonical
URLs for SEO and web compatibility.
1.1. Problem Statement
Current AI crawler behavior (2025) demonstrates:
1. *Bandwidth Waste*: Fetching full HTML documents when only core
content is needed
2. *Token Overhead*: Processing boilerplate (navigation, footers)
consumes 86% of tokens
3. *Redundant Fetches*: No efficient skip mechanism when content
unchanged
4. *Lack of Verification*: No cryptographic proof of content
delivery
Measured impact (from live deployments):
* HTML-only retrieval: 103 KB average (13,900 tokens)
* TCT JSON delivery: 17.7 KB average (1,960 tokens)
* *Savings: 83% bandwidth, 86% tokens*
Jurkovikj Expires 8 May 2026 [Page 4]
Internet-Draft Collab-Tunnel November 2025
1.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.
*C-URL (Canonical URL)*: The human-readable URL of a web resource,
typically serving HTML.
*M-URL (Machine URL)*: A deterministically mapped endpoint serving
machine-readable structured content for the same resource.
*Template-Invariant Fingerprint*: A cryptographic hash computed from
normalized core content, stable across presentation changes.
*Core Content*: The primary informational content of a resource,
excluding presentational boilerplate.
2. Protocol Overview
The Collaboration Tunnel Protocol consists of four coordinated
mechanisms:
1. *Bidirectional Discovery*: Explicit C-URL <-> M-URL handshake
preventing SEO conflicts
2. *Template-Invariant Fingerprinting*: Normalized content hashing
for stable cache validation
3. *Conditional Request Discipline*: Strict If-None-Match precedence
and 304 responses
4. *Sitemap-First Verification*: Zero-fetch skip logic when content
unchanged
2.1. Architecture
Jurkovikj Expires 8 May 2026 [Page 5]
Internet-Draft Collab-Tunnel November 2025
+------------------------+ +----------------------+
| Publisher (Origin) | | Automated Agent |
+------------------------+ +----------------------+
| | | |
| C-URL (HTML) |<---------| 1. Fetch Sitemap |
| +- <link rel= | | |
| | "alternate" | | 2. Compare Hashes |
| | type="application/ | | (Zero-Fetch) |
| | json" | | |
| | href="/llm/"> | | 3. If Changed: |
| | | GET /llm/ |
| M-URL (/llm/) |<---------| If-None-Match |
| +- Link: canonical | | |
| +- ETag: sha256-... | | |
| +- Content-Type: JSON |--------->| 4. 304 or 200+JSON |
| | | |
| /llm-sitemap.json | | 5. Cache ETag |
| +- {cUrl, mUrl, |<---------| |
| | contentHash} | | |
+------------------------+ +----------------------+
3. Protocol Requirements
This section defines the normative requirements for TCT compliance.
3.1. MUST Requirements
Implementations MUST:
1. *Bidirectional Discovery*
* C-URL HTML MUST include <link rel="alternate"
type="application/json"> pointing to M-URL
* M-URL response MUST include Link: <c-url>; rel="canonical"
HTTP header
2. *Validators*
* M-URL response MUST include ETag header
* M-URL response SHOULD include Last-Modified header when
available
* Sitemap MUST include contentHash field for each URL
3. *Conditional Requests*
Jurkovikj Expires 8 May 2026 [Page 6]
Internet-Draft Collab-Tunnel November 2025
* M-URL responses MUST use strong ETags for template-invariant
fingerprints: "sha256-<64 lowercase ASCII hex chars>"
* Server MUST honor If-None-Match header
* Server MUST return 304 Not Modified when ETag matches
* Server MUST give If-None-Match precedence over If-Modified-
Since (see [RFC9110], Section 13.1.2)
* If-Range requires a strong validator. If the If-Range
validator is weak or does not match, the server MUST ignore
the Range header and send 200 OK with the full representation
(per [RFC9110], Section 13.1.5)
* Servers MUST NOT assemble ranges across different encodings;
ranges apply only to the selected representation variant.
4. *304 Response*
* Response MUST NOT include message body
* Servers MUST include ETag if the corresponding 200 would;
otherwise SHOULD include ETag
* Servers SHOULD include Cache-Control (consistent with
[RFC9110], Section 15.4.5)
5. *HEAD Support*
* Servers SHOULD support HEAD requests for all M-URLs and
sitemaps
* HEAD responses MUST return the same validators and cache
headers as GET and MUST NOT include a message body
* Body-dependent headers (e.g., Content-Length) MAY reflect the
size of the corresponding GET response
* This behavior applies across HTTP/1.1, HTTP/2, and HTTP/3
* Implementations MUST avoid hop-by-hop headers on M-URLs and
sitemaps and SHOULD NOT use transfer-codings or trailers on
these responses
6. *Sitemap Parity*
Jurkovikj Expires 8 May 2026 [Page 7]
Internet-Draft Collab-Tunnel November 2025
* Sitemap contentHash value MUST equal M-URL ETag value
(excluding quotes)
* Example: M-URL ETag "sha256-abc" -> Sitemap contentHash
sha256-abc
* See "Template-Invariant Fingerprinting" and "ETag Generation"
for computation and format details
7. *Canonical Verification (Agents)*
* Agents MUST verify that the M-URL response includes Link:
<c-url>; rel="canonical" and that the canonical URL matches
the expected C-URL before processing
* If the canonical link is missing or mismatched, agents SHOULD
treat the endpoint as non-compliant and skip ingestion
* If HTML <link rel="alternate"> discovery and the M-URL's
self-declared canonical conflict, agents SHOULD prefer the
M-URL's self-declared canonical and flag for operator review
8. *Protected Sitemaps*
* Sitemaps that list protected M-URLs MUST NOT be served
without access controls equivalent to those applied to the
corresponding M-URLs
9. *Client Parity Behavior (Agents)*
* Agents MUST NOT attempt to recompute the fingerprint from
C-URL HTML to verify parity
* Agents MUST verify parity by comparing the sitemap
contentHash value to the M-URL ETag value (excluding quotes)
* The comparison is a simple string equality check: contentHash
=== cleanETag(ETag)
* Agents SHOULD NOT implement the normalization algorithm for
compliance purposes; parity verification is sufficient
Jurkovikj Expires 8 May 2026 [Page 8]
Internet-Draft Collab-Tunnel November 2025
10. *Content Pages Only* - Publishers SHOULD NOT provide M-URLs for
archive, category, tag, search, or date-based listing pages;
where requested, servers SHOULD return 404 - Deployments with
strong rationale MAY include such endpoints but MUST maintain
parity semantics - Sitemaps SHOULD include only content pages
(posts, articles, pages) - A homepage MAY be included only if it
represents stable content
3.2. SHOULD Recommendations
Implementations SHOULD:
1. *Cache-Control*
* Use: max-age=0, must-revalidate, stale-while-revalidate=60,
stale-if-error=86400
* Rationale: Enables revalidation with graceful stale serving
2. *Vary Header*
* Include: Vary: Accept-Encoding
* Rationale: Content varies by compression (gzip, br)
3. *Strong ETags*
* Use strong ETags ("sha256-...") for TCT semantic fingerprints
(per MUST requirement #3)
* Rationale: Normalized content produces byte-identical JSON
responses; strong validators ensure reliable cache
compatibility
* Note: Strong ETags MAY be used for representation-specific
caching outside TCT parity (e.g., CDN byte-level caching)
4. *Content Pages Only*
* Return 404 for M-URL requests to archive pages
* Include only content pages in sitemap
3.3. MAY Extensions
Implementations MAY:
1. *Policy Descriptor*
Jurkovikj Expires 8 May 2026 [Page 9]
Internet-Draft Collab-Tunnel November 2025
* Servers MAY advertise a machine-readable policy via Link:
</llm-policy.json>; rel="describedby"; type="application/json"
* The policy document format is informative and out of scope for
the core protocol (see Publisher Policy Descriptor section)
2. *Additional Integrity*
* Use Content-Digest header ([RFC9530])
* Use HTTP Message Signatures ([RFC9421])
3. *Additional Formats*
* Provide PDF JSON alternates
* Provide receipt/proof systems
4. Bidirectional Discovery
Note: Path names in examples are non-normative. This specification
does not require any specific URL paths. Example path "/llm/" is
illustrative. Servers MAY choose alternative slugs or publish
mappings. Agents MUST NOT assume a fixed path and SHOULD discover
M-URLs via HTML rel="alternate", HTTP Link headers, or the JSON
sitemap.
4.1. C-URL to M-URL Mapping
The C-URL MUST include an HTML <link> element in the document <head>:
<link rel="alternate"
type="application/json"
href="https://example.com/post/llm/">
*Attributes:*
* rel="alternate": Indicates alternate representation ([RFC8288])
* type="application/json": Machine-readable format
* href: Absolute or relative URL to M-URL
4.2. M-URL to C-URL Canonicalization
The M-URL response MUST include an HTTP Link header with
rel="canonical":
Jurkovikj Expires 8 May 2026 [Page 10]
Internet-Draft Collab-Tunnel November 2025
Link: <https://example.com/post/>; rel="canonical"
This establishes bidirectional verification and prevents SEO
duplication. The canonical link relation is registered by [RFC6596].
4.3. Deterministic Mapping
M-URLs SHOULD follow a deterministic pattern from C-URLs.
*Non-normative examples*: Append a slug to the C-URL path, such as
/llm/.
Example: - C-URL: https://example.com/post/ - M-URL:
https://example.com/post/llm/
*Guidance*: - These path patterns are examples, not protocol
requirements. If a preferred slug collides with existing site
routes, publishers MAY choose an alternate (e.g., /api/llm/,
/content/llm/) or publish a mapping in a site-level manifest. -
Agents MUST NOT assume a fixed path. Agents SHOULD discover M-URLs
via HTML <link rel="alternate" type="application/json">, HTTP Link
headers, or the JSON sitemap.
*Migration Note*: Publishers MAY use HTTP 308 Permanent Redirect to
migrate from legacy paths to preferred endpoints and SHOULD list only
the primary M-URL in the sitemap.
*Sitemap Discovery*:
Publishers SHOULD advertise the sitemap via one or both of:
1. *Link header* (RECOMMENDED) on the homepage or C-URL responses:
Link: </llm-sitemap.json>; rel="index"; type="application/json"
1. *Well-known URI* (OPTIONAL): Agents MAY check /.well-known/llm-
sitemap.json. The .well-known URI convention follows [RFC8615].
Note: The well-known URI is not registered in IANA for -00; future
versions may formalize this. Agents SHOULD try the Link header
first, then fall back to well-known URI if needed.
4.4. Content Pages Only
Publishers SHOULD NOT provide M-URLs for archive, category, tag,
search, or date-based listing pages; where requested, servers SHOULD
return 404. Deployments with strong rationale MAY include such
endpoints but MUST maintain parity semantics.
Jurkovikj Expires 8 May 2026 [Page 11]
Internet-Draft Collab-Tunnel November 2025
*Rationale:*
* Archive pages contain navigation and lists, not primary content
* Template-invariant fingerprinting is designed for stable content,
not dynamic lists
* Archive pages change frequently as new content is published
*Implementation:*
* Publishers SHOULD return HTTP 404 for M-URL requests to archive
pages
* Sitemaps SHOULD include only content page URLs, not archives
* Homepage MAY be included if it represents stable content
*Dynamic Homepage Guidance:*
If the homepage displays a dynamic content roll-up (e.g., recent
posts, latest articles), publishers SHOULD prefer one of:
* Provide a synthesized stable overview representing the site (name,
description, purpose)
* Include a stable "About" page as the first sitemap item instead of
the homepage
Rationale: Dynamic homepages change frequently and may not provide
valuable semantic content for automated agents. - CMS guidance (non-
normative): For platforms like WordPress, exclude archive-like routes
(e.g., category, tag, search, date, author) from M-URL handling and
return 404 rather than 200 with empty payload. Ensure only singular
content types (posts, pages, articles) emit M-URLs and sitemap
entries.
*Content page examples:* - Blog posts: /blog/understanding-tct/ -
Articles: /news/2025/protocol-launch/ - Static pages: /about/,
/contact/
*Archive page examples (should NOT have M-URLs):* - Category
archives: /category/technology/ - Tag archives: /tag/web-protocols/ -
Date archives: /2025/10/ - Search results: /search/?q=protocol -
Author archives: /author/john/
5. Template-Invariant Fingerprinting
Jurkovikj Expires 8 May 2026 [Page 12]
Internet-Draft Collab-Tunnel November 2025
5.1. Publisher Source of Content (Informative)
The M-URL JSON payload SHOULD be produced from the platform's core
content body (e.g., the WordPress post content field, a CMS article
body), independent of the theme or template layer. This ensures the
fingerprint is template-invariant.
Publishers MAY include additional semantic text in the content field
to make the fingerprint sensitive to changes in those elements. For
example:
* Title: Including the resource title ensures title changes produce
new fingerprints
* Media descriptions: Including image alt text or <figcaption>
content ensures accessibility metadata is tracked
* Deterministic order: If multiple elements are included, use a
consistent order (e.g., title, blank line, main content)
Example reconstructed content:
Understanding the Collaboration Tunnel Protocol
The Collaboration Tunnel Protocol enables efficient content delivery.
Diagram showing protocol flow. The protocol achieves 80-90% bandwidth
reduction through conditional requests.
This approach balances template-invariance (content independent of
presentation) with semantic completeness (title and media
descriptions included). Publishers using this approach should ensure
all included text goes through the same normalization pipeline
defined in the next section.
*Example of content Field Construction:*
A publisher implementation might construct the content field by
combining several data sources in a deterministic order.
Input Data: - Title: TCT Protocol Guide - Body Paragraph 1: The
protocol is simple. - Image Alt: A flow diagram - Body Paragraph 2:
It saves bandwidth.
Resulting content string in the JSON Payload:
Jurkovikj Expires 8 May 2026 [Page 13]
Internet-Draft Collab-Tunnel November 2025
TCT Protocol Guide
The protocol is simple.
[Image: A flow diagram]
It saves bandwidth.
This creates a readable representation that is also a stable and
reliable input for the fingerprinting algorithm.
5.2. Normalization Algorithm
To generate the template-invariant fingerprint, the server MUST
operate on the JSON payload's content field (not on the C-URL HTML),
applying the following steps in order:
1. Decode HTML Entities: Decode any HTML entities present in the
content string (e.g., & -> &, — -> -)
2. Apply Unicode Normalization: Apply Unicode Normalization Form KC
(NFKC) as defined in Unicode Standard Annex #15
3. Apply Unicode Case Folding: Convert to lowercase using the
standard, locale-independent Unicode case-folding algorithm as
defined in the Unicode Standard
4. Remove Control Characters: Remove all characters in the Unicode
general category "Control" (Cc), which includes characters U+0000
through U+001F and U+007F through U+009F. Preserve only U+0009
(TAB), U+000A (LINE FEED), and U+000D (CARRIAGE RETURN) for
subsequent whitespace collapsing.
5. Collapse Whitespace: Replace any sequence of one or more ASCII
whitespace characters (U+0020 SPACE, U+0009 TAB, U+000A LINE
FEED, U+000D CARRIAGE RETURN) with a single ASCII SPACE (U+0020)
6. Trim Whitespace: Remove any leading or trailing ASCII SPACE
characters
7. Compute Hash: Compute the SHA-256 hash over the resulting string
(encoded as UTF-8)
The strong ETag MUST be "sha256-<64 lowercase ASCII hex chars>" from
this hash. The sitemap contentHash MUST be sha256-<64 lowercase
ASCII hex chars> from the same hash (without the W/ prefix and
quotes).
Jurkovikj Expires 8 May 2026 [Page 14]
Internet-Draft Collab-Tunnel November 2025
Example (pseudocode):
function generateFingerprint(contentString):
normalized = contentString
.decodeEntities()
.unicodeNormalize('NFKC')
.casefold()
.removeControlChars()
.collapseWhitespace()
.trim()
return "sha256-" + sha256(normalized)
Note: This normalization operates on the plain-text content field in
the JSON payload, not on HTML from the C-URL.
Normalization uses Unicode NFKC [UAX15] and Unicode case folding
[Unicode-CaseFolding]; named character references are decoded per the
HTML Living Standard [WHATWG-HTML].
5.3. Deterministic JSON Serialization (Normative)
Implementations MUST use deterministic JSON serialization when
generating M-URL responses to ensure that identical inputs yield
byte-identical JSON.
*Required Properties:*
* *Stable object key order:* Lexicographic ordering by Unicode
codepoint at every depth
* *Preserve array order:* Arrays MUST maintain element order as
defined
* *UTF-8 encoding:* Without BOM; emit exactly one JSON document; no
trailing newline
* *Compact serialization:* No pretty-print; no extraneous whitespace
* *Consistent escaping per [RFC8259]:*
- Escape quotation mark (U+0022) and backslash (U+005C)
- Do not escape solidus (U+002F)
- Emit Unicode as UTF-8; use \uXXXX only where required by
[RFC8259]
Jurkovikj Expires 8 May 2026 [Page 15]
Internet-Draft Collab-Tunnel November 2025
* *Numbers:* MUST be in minimal canonical form (no leading zeros, no
"+", lowercase "e")
* *Non-finite numbers:* JSON numbers MUST NOT represent NaN or
infinite values. Producers MUST NOT emit non-finite values;
consumers encountering them MUST treat the payload as invalid.
Values that cannot be portably represented SHOULD be encoded as
strings with schema guidance
*Deterministic field inclusion:*
The set of fields included and their values for a given resource MUST
be deterministic. Fields that vary independently of the normalized
content MUST NOT be included unless they are a deterministic function
of that content.
*Recommendation:*
Implementations SHOULD use [RFC8785] (JSON Canonicalization Scheme)
or document an equivalent deterministic serialization profile to
ensure cross-platform consistency.
5.4. Strong ETag and Parity (Normative)
Servers emitting strong validators MUST ensure that the ETag value
changes whenever the final serialized JSON payload bytes change;
equality of strong ETag values MUST imply byte-identical
representations.
The 64 hexadecimal digits in the hash value MUST be lowercase ASCII.
ETag values MUST be sent as a quoted-string per [RFC9110].
5.4.1. Method A: Canonical JSON Strong-Byte (Recommended)
*Computation:*
1. Build the JSON response object WITHOUT the hash field
2. Canonicalize the JSON per the deterministic serialization
requirements above
3. Compute F = SHA-256(canonical_json_bytes) as 64 hexadecimal
characters
4. Set the hash value: hash_value = "sha256-" + F
5. Add the hash field to the JSON payload: payload.hash = hash_value
Jurkovikj Expires 8 May 2026 [Page 16]
Internet-Draft Collab-Tunnel November 2025
6. Set HTTP headers:
* ETag: "sha256-" + F
* Sitemap: contentHash: "sha256-" + F
7. Servers MUST canonicalize the final payload (now including the
hash field) before sending, using the same deterministic
serialization profile
*Rationale:*
This method guarantees strong ETag semantics even as the protocol
evolves to add new fields. Any change to the JSON representation
correctly changes the ETag, ensuring byte-identical validation per
[RFC9110].
Computing the ETag over the canonical form of the payload without the
hash field still satisfies strong validator semantics because the
final payload bytes are a deterministic function of that canonical
pre-hash payload and the ETag value.
Servers SHOULD compute F over identity-coded (uncompressed) canonical
bytes and MAY reuse the same ETag across compressed variants; servers
MUST set Vary: Accept-Encoding.
*Example:*
json_without_hash = {
"profile": "tct-1",
"canonical_url": "https://example.com/post/",
"title": "Article Title",
"content": "Normalized content text..."
}
canonical_bytes = canonicalize_json(json_without_hash)
F = sha256(canonical_bytes).hexdigest() // 64 hex chars
hash_value = "sha256-" + F
json_with_hash = json_without_hash
json_with_hash["hash"] = hash_value
response.setHeader("ETag", '"' + hash_value + '"')
response.send(json_with_hash)
Jurkovikj Expires 8 May 2026 [Page 17]
Internet-Draft Collab-Tunnel November 2025
5.4.2. Method B: Content-Locked Strong-Content (Allowed with
Restrictions)
*Computation:*
1. Extract and normalize content per the 6-step normalization
algorithm
2. Compute F = SHA-256(normalized_content_utf8_bytes) as 64
hexadecimal characters
3. Set the hash value: hash_value = "sha256-" + F
4. Build the JSON payload deterministically from the normalized
content
5. Set HTTP headers:
* ETag: "sha256-" + F
* Sitemap: contentHash: "sha256-" + F
* JSON payload: hash: "sha256-" + F
*Restrictions:*
This method is ONLY valid if:
* The ENTIRE JSON representation is a deterministic function of the
normalized content and fixed protocol constants
* NO field may vary independently of the normalized content
* Adding or changing any field REQUIRES recomputing the hash from
updated content
*Rationale:*
If the final JSON bytes are strictly determined by content, then
content-hashing produces the same result as JSON-hashing. This
preserves template-invariance: same content text produces the same
hash regardless of HTML/theme presentation.
*Caution:*
Jurkovikj Expires 8 May 2026 [Page 18]
Internet-Draft Collab-Tunnel November 2025
Future protocol versions that add metadata fields (e.g., language,
author, published_date) independent of content text would violate
strong semantics with this method. Such deployments MUST migrate to
Method A.
5.5. Parity Rule (Normative)
Sitemap contentHash, JSON payload hash field, and M-URL ETag value
MUST satisfy:
contentHash == clean(ETag) == payload.hash
Where clean(ETag) removes surrounding quotes from the ETag header
value.
*Example:*
* HTTP Header: ETag: "sha256-2c26b46b68ffc68f..."
* Sitemap: contentHash: sha256-2c26b46b68ffc68f...
* JSON Payload: "hash": "sha256-2c26b46b68ffc68f..."
*Verification:*
Clients MUST verify parity through string equality and MUST NOT
recompute hashes from HTML. Clients that detect parity violations
SHOULD log a warning and MAY reject the response.
5.6. Template-Invariance
TCT's template-invariance property means that HTML presentation
changes (theme updates, CSS/JavaScript modifications, navigation
restructuring) do not affect the protocol's hash values, provided the
core content (title + body text) remains unchanged.
*With Method A (Canonical JSON Strong-Byte):*
* HTML changes -> No effect on normalized content -> No effect on
JSON -> ETag unchanged OK
* JSON field addition/change -> JSON bytes change -> ETag changes OK
* Result: Template-invariance preserved AND strong ETag semantics
correct
*With Method B (Content-Locked Strong-Content):*
Jurkovikj Expires 8 May 2026 [Page 19]
Internet-Draft Collab-Tunnel November 2025
* HTML changes -> No effect on normalized content -> ETag unchanged
OK
* Content changes -> Hash changes -> ETag changes OK
* Independent JSON field changes -> FAIL Would violate strong
semantics (not allowed)
*Summary:*
Template-invariance addresses HTML/theme independence. Strong ETag
semantics address JSON byte-identity. Both properties are compatible
when JSON is deterministic.
6. Conditional Request Discipline
6.1. If-None-Match Precedence
When both If-None-Match and If-Modified-Since headers are present,
servers MUST give If-None-Match precedence per [RFC9110],
Section 13.1.2. This means:
1. Evaluate If-None-Match first
2. If ETag matches, return 304 Not Modified (ignore If-Modified-
Since)
3. If ETag doesn't match, process If-Modified-Since (if present)
*Rationale:* ETags provide stronger validation than modification
dates, especially for semantic fingerprints.
6.2. 304 Not Modified Response
When the ETag matches the If-None-Match value:
1. Server MUST respond with 304 Not Modified
2. Response MUST NOT include a message body. Servers MUST include
ETag if the corresponding 200 OK would include it; otherwise
SHOULD include ETag. Servers SHOULD include Cache-Control (per
[RFC9111]) and MAY include Last-Modified
*Example:*
Jurkovikj Expires 8 May 2026 [Page 20]
Internet-Draft Collab-Tunnel November 2025
HTTP/1.1 304 Not Modified
ETag: "sha256-2c26b46b68ffc68f..."
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
Cache-Control: max-age=0, must-revalidate
Cache-Control: stale-while-revalidate=60
Cache-Control: stale-if-error=86400
Vary: Accept-Encoding
6.3. Replay and Stale Intermediaries
If an agent receives a 200 whose ETag is older than its cached parity
while the sitemap contentHash matches the cached parity, it SHOULD
treat the cached/sitemap state as authoritative unless the server
signals otherwise (e.g., newer Last-Modified or sitemap value). The
agent SHOULD revalidate end-to-end (e.g., Cache-Control: no-cache +
If-None-Match) before adopting a regression.
6.4. Cache-Control Directives
M-URL responses SHOULD use:
Cache-Control: max-age=0, must-revalidate
Cache-Control: stale-while-revalidate=60
Cache-Control: stale-if-error=86400
*Directives:* - max-age=0: Require revalidation before serving from
cache - must-revalidate: Do not serve stale without successful
revalidation - stale-while-revalidate=60: Serve stale while
revalidating in background (60s window) - stale-if-error=86400: Serve
stale if origin unavailable (24h window)
Note: Avoid private on M-URLs and sitemaps (they are cacheable by
shared caches).
6.5. Vary Header
Responses SHOULD include Vary: Accept-Encoding to indicate
compression variance:
Vary: Accept-Encoding
M-URL responses primarily vary by compression (gzip, brotli), not by
content type (always application/json).
Servers SHOULD NOT vary on User-Agent for M-URLs and sitemaps to
preserve cacheability and reduce fragmentation.
Jurkovikj Expires 8 May 2026 [Page 21]
Internet-Draft Collab-Tunnel November 2025
6.6. HEAD Request Support
Servers SHOULD support HEAD requests for all M-URLs and sitemaps.
HEAD responses MUST: - Return same HTTP headers as equivalent GET
request - NOT include a message body - Include all validators (ETag,
Last-Modified, Cache-Control)
*Example:*
HEAD /post/llm/ HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
ETag: "sha256-abc123..."
Last-Modified: Wed, 21 Oct 2025 07:28:00 GMT
Cache-Control: max-age=0, must-revalidate, stale-while-revalidate=60
Vary: Accept-Encoding
Content-Type: application/json
Content-Length: 1234
This enables efficient validation without transferring the full
response body.
7. Sitemap-First Verification
7.1. JSON Sitemap Format
Publishers SHOULD provide a machine-readable sitemap at a well-known
location (e.g., /llm-sitemap.json).
Publishers MAY also include a Sitemap: directive in robots.txt
pointing to the JSON sitemap; agents MAY use it as a discovery hint.
If both XML and JSON sitemaps are present, agents that implement this
protocol SHOULD prefer the JSON sitemap for TCT.
*Schema:*
Jurkovikj Expires 8 May 2026 [Page 22]
Internet-Draft Collab-Tunnel November 2025
{
"version": 1,
"profile": "tct-1",
"items": [
{
"cUrl": "https://example.com/post/",
"mUrl": "https://example.com/post/llm/",
"modified": "2025-10-01T12:34:56Z",
"contentHash": "sha256-2c26b46b68ffc68f..."
}
]
}
*Fields:*
* version (integer): Sitemap format version (currently 1)
* profile (string, RECOMMENDED): Protocol version identifier (e.g.,
"tct-1"). Enables clients to detect protocol capabilities and
maintain forward compatibility as the specification evolves.
* items (array): List of URL pairs
- cUrl (string, required): Canonical URL
- mUrl (string, required): Machine URL
- modified (string, [RFC3339]): Last modification timestamp
- contentHash (string, required): Template-invariant fingerprint
(same as M-URL ETag)
*Parity Rule:*
The sitemap contentHash value MUST match the M-URL ETag header value,
excluding quotes. This enables zero-fetch skip optimization: clients
compare sitemap hash to cached ETag without fetching the M-URL.
*Forward Compatibility:*
Clients MUST ignore unknown fields in the sitemap JSON. Servers MAY
add additional fields to support future protocol versions. Agents
SHOULD read the profile field when present; unknown profile values
SHOULD NOT cause ingestion failure but MAY be logged for analysis.
Jurkovikj Expires 8 May 2026 [Page 23]
Internet-Draft Collab-Tunnel November 2025
7.2. Sitemap Scalability
Publishers and agents SHOULD consider scalability for large sites:
* Publishers MAY split sitemaps into an index (a sitemap-of-
sitemaps) to segment large URL sets (analogous to XML Sitemaps
sitemapindex)
* Servers SHOULD support compression (e.g., Content-Encoding: gzip
or br) for sitemap responses; agents SHOULD accept compressed
responses
* Agents SHOULD use streaming JSON parsers for large sitemaps and
enforce a maximum sitemap size (e.g., 100 MB)
* Servers SHOULD keep per-item objects compact (RECOMMENDED <= 2
KB). Servers MUST bound total sitemap size by an operator-
configured budget. When budgets would be exceeded (RECOMMENDED <=
50,000 items per sitemap), servers SHOULD publish a sitemap index
and split content
*Sitemap Index (Large Sites):*
For sites with thousands of URLs, publishers SHOULD segment sitemaps
using a sitemap index (analogous to XML Sitemaps sitemapindex). A
formal JSON sitemap index schema MAY be specified in future protocol
versions. Agents SHOULD support consuming multiple sitemap files.
*Homepage Handling:*
Publishers SHOULD include the site homepage as the *first item* in
the sitemap array. This provides automated agents with immediate
access to site-level context (site name, description, purpose) before
processing individual content pages.
For homepages that display dynamic content listings (blog roll,
latest posts), publishers MAY synthesize stable content representing
the site overview rather than the dynamic list.
*Example with homepage first:*
Jurkovikj Expires 8 May 2026 [Page 24]
Internet-Draft Collab-Tunnel November 2025
{
"version": 1,
"profile": "tct-1",
"items": [
{
"cUrl": "https://example.com/",
"mUrl": "https://example.com/llm/",
"modified": "2025-10-15T08:00:00Z",
"contentHash": "sha256-abc123..."
},
{
"cUrl": "https://example.com/about/",
"mUrl": "https://example.com/about/llm/",
"modified": "2025-10-01T10:00:00Z",
"contentHash": "sha256-def456..."
}
]
}
*Sitemap HTTP Response:*
GET /llm-sitemap.json HTTP/1.1
Host: example.com
HTTP/1.1 200 OK
Content-Type: application/json
ETag: "sha256-sitemap-fingerprint"
Last-Modified: Wed, 21 Oct 2025 12:00:00 GMT
Cache-Control: max-age=0, must-revalidate, stale-while-revalidate=60
Vary: Accept-Encoding
Content-Length: 4567
{
"version": 1,
"profile": "tct-1",
"items": [...]
}
*Conditional Sitemap Fetch:*
GET /llm-sitemap.json HTTP/1.1
Host: example.com
If-None-Match: "sha256-sitemap-fingerprint"
HTTP/1.1 304 Not Modified
ETag: "sha256-sitemap-fingerprint"
Cache-Control: max-age=0, must-revalidate, stale-while-revalidate=60
Jurkovikj Expires 8 May 2026 [Page 25]
Internet-Draft Collab-Tunnel November 2025
Clients SHOULD use conditional requests for sitemap to avoid
unnecessary bandwidth when sitemap unchanged.
7.3. Error Handling (Informative)
*Malformed sitemap:* Agents SHOULD treat this as non-fatal; skip
entries that fail structural validation; log and continue.
*ETag/contentHash mismatch:* Agents SHOULD treat the endpoint ETag as
authoritative, process the change, and update caches. Publishers
SHOULD publish sitemaps atomically or include Last-Modified.
*M-URL unavailable:* Agents MAY defer the fetch or fall back to the
C-URL HTML as a last resort; publishers SHOULD return a 4xx/5xx
rather than an empty 200.
*HTTP Status Code Handling:*
Agents SHOULD respect common HTTP status codes for retries and
backoff. If a server responds with 410 Gone, the agent SHOULD treat
the resource as permanently deleted. If a server responds with 429
Too Many Requests or 503 Service Unavailable, the agent SHOULD honor
the Retry-After header if present.
7.4. Zero-Fetch Skip Logic
Automated agents SHOULD:
1. Fetch /llm-sitemap.json periodically
2. Compare contentHash values to locally cached hashes
3. *If hash unchanged*: Skip fetching both C-URL and M-URL (zero-
fetch optimization)
4. *If hash changed*: Issue conditional GET to M-URL with If-None-
Match
This enables 90%+ skip rate for unchanged content.
*Example workflow:*
Jurkovikj Expires 8 May 2026 [Page 26]
Internet-Draft Collab-Tunnel November 2025
Agent: Fetch /llm-sitemap.json
Agent: item.contentHash = "sha256-abc123..."
Agent: cachedHash = lookup(item.mUrl)
if (item.contentHash === cachedHash):
// Zero-fetch: Content unchanged, skip all requests
skip()
else:
// Hash changed, fetch with conditional request
GET item.mUrl
Headers: If-None-Match: "sha256-abc123..."
if (response.status == 304):
// Still matched at endpoint, update cache
cache(item.mUrl, item.contentHash)
else:
// Content changed, process new data
process(response.body)
cache(item.mUrl, response.headers['ETag'])
8. Publisher Policy Descriptor
This section is informative.
Publishers MAY provide a machine-readable policy descriptor at a
well-known location (e.g., /llm-policy.json or /.well-known/llm-
policy.json) to communicate usage terms, rate limits, and content
licensing preferences to automated agents. Example paths are non-
normative.
8.1. Policy Endpoint
The policy descriptor SHOULD be available at a stable URL. Example
paths (non-normative):
https://example.com/llm-policy.json
https://example.com/.well-known/llm-policy.json
8.2. JSON Schema
Jurkovikj Expires 8 May 2026 [Page 27]
Internet-Draft Collab-Tunnel November 2025
{
"profile": "tct-policy-1",
"version": 1,
"effective": "2025-10-01T00:00:00Z",
"updated": "2025-10-15T12:00:00Z",
"policy_urls": {
"terms_of_service": "https://example.com/terms/",
"payment_info": "https://example.com/pricing/",
"contact": "https://example.com/contact/"
},
"purposes": {
"allow_ai_input": true,
"allow_ai_train": false,
"allow_search_indexing": true
},
"requirements": {
"attribution_required": true,
"link_back_required": false,
"notice_required": true
},
"rate_hints": {
"max_requests_per_second": null,
"max_requests_per_day": 10000,
"note": "Advisory limits, honor system"
}
}
*Fields:*
* profile (string): Policy schema version identifier (e.g., "tct-
policy-1")
* version (integer): Policy revision number
* effective (string, RFC 3339): When policy took effect
* updated (string, RFC 3339): Last policy modification
* policy_urls (object): URLs to human-readable policy documents
- terms_of_service: Legal terms URL
- payment_info: Pricing/billing information URL (for paid access)
Jurkovikj Expires 8 May 2026 [Page 28]
Internet-Draft Collab-Tunnel November 2025
- contact: Publisher contact for licensing inquiries
* purposes (object): Usage permissions
- allow_ai_input: Content may be used as AI input (RAG, context)
- allow_ai_train: Content may be used for model training
- allow_search_indexing: Content may be indexed for search
* requirements (object): Usage conditions
- attribution_required: Must credit publisher when using content
- link_back_required: Must link to canonical URL when
republishing
- notice_required: Must notify publisher of commercial use
* rate_hints (object): Advisory crawl rate limits (non-binding)
- max_requests_per_second: Requests per second limit (null = no
limit)
- max_requests_per_day: Requests per day limit
- note: Additional guidance
Rate hints are advisory only; enforcement, payment, and economic
arrangements are out of scope for this specification. Vocabulary
alignment with IETF AIPREF is expected as that work matures.
8.3. Discovery
The policy descriptor SHOULD be linked from the sitemap with a
describedby Link header (example paths only):
Link: </llm-policy.json>; rel="describedby"; type="application/json"
Automated agents SHOULD:
1. Fetch /llm-policy.json before crawling
2. Honor stated usage restrictions
3. Respect rate hints to avoid overwhelming origin
4. Review terms before commercial use
Jurkovikj Expires 8 May 2026 [Page 29]
Internet-Draft Collab-Tunnel November 2025
This specification uses registered relations (alternate/index/
describedby). A dedicated relation for TCT sitemaps might be
registered in the future; this document does not create new link
relations.
8.4. Alignment with IETF AIPREF
This policy format is designed to complement the IETF AIPREF (AI
Preferences) proposal, providing machine-readable expressions of
publisher preferences for automated agent behavior.
9. M-URL Response Format
9.1. Content-Type
M-URL responses MUST set Content-Type: application/json:
Content-Type: application/json; charset=utf-8
9.2. JSON Payload Schema
*Minimal required fields:*
{
"profile": "tct-1",
"canonical_url": "https://example.com/post/",
"title": "Article Title",
"content": "Core article content...",
"hash": "sha256-2c26b46b68ffc68f..."
}
*Fields:*
* profile (string, RECOMMENDED): Protocol version identifier (e.g.,
"tct-1"). Future versions (e.g., "tct-2") can introduce new
fields while maintaining backward compatibility.
* canonical_url (string, required): The C-URL for this resource
* title (string, required): Resource title
* content (string, required): Plain-text core content (UTF-8). This
field is the input to the normalization algorithm. The content
field MUST NOT contain HTML tags or markup. Publishers MUST strip
or escape any embedded HTML before inclusion. To ensure
fingerprint stability, publishers SHOULD avoid including volatile,
non-semantic elements (e.g., dynamic view counts, timestamps) in
this string. Publishers SHOULD provide content independent of
Jurkovikj Expires 8 May 2026 [Page 30]
Internet-Draft Collab-Tunnel November 2025
template/theme presentation. Publishers MAY include semantic
metadata (such as title or media captions) to create a more
complete fingerprint.
* hash (string, required): Template-invariant fingerprint. MUST
equal the M-URL ETag value excluding quotes. This is the same
value as the sitemap contentHash field. Format: sha256-<64 hex>.
Example: if M-URL ETag is "sha256-abc123", then hash is
sha256-abc123 and sitemap contentHash is sha256-abc123.
*Forward Compatibility:*
Clients MUST ignore unknown fields in the JSON payload. Servers MAY
add additional fields to support future protocol versions or domain-
specific metadata. Agents SHOULD read the profile field when
present; unknown values SHOULD NOT cause ingestion failure but MAY be
logged.
*Extended fields example:*
{
"profile": "tct-1",
"canonical_url": "https://example.com/post/",
"title": "Article Title",
"language": "en-US",
"published": "2025-10-01T10:00:00Z",
"modified": "2025-10-15T14:30:00Z",
"content": "Core article content...",
"hash": "sha256-2c26b46b68ffc68f...",
"structured_data": {
"@context": "https://schema.org",
"@type": "Article",
"headline": "Article Title"
}
}
9.3. Complete Response Example
Jurkovikj Expires 8 May 2026 [Page 31]
Internet-Draft Collab-Tunnel November 2025
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
ETag: "sha256-2c26b46b68ffc68f..."
Link: <https://example.com/post/>; rel="canonical"
Last-Modified: Wed, 15 Oct 2025 14:30:00 GMT
Cache-Control: max-age=0, must-revalidate
Cache-Control: stale-while-revalidate=60
Cache-Control: stale-if-error=86400
Vary: Accept-Encoding
Content-Length: 1234
{
"profile": "tct-1",
"canonical_url": "https://example.com/post/",
"title": "Understanding the Collaboration Tunnel Protocol",
"language": "en",
"published": "2025-10-01T10:00:00Z",
"modified": "2025-10-15T14:30:00Z",
"content": "The Collaboration Tunnel Protocol enables...",
"hash": "sha256-2c26b46b68ffc68f..."
}
10. Operational Considerations (Informative)
This section provides non-normative operational guidance for
deployers and automated agents.
*Migration and Path Collisions* - If a preferred slug (e.g., /llm/)
collides with existing routes, choose an alternate (e.g., /api/llm/,
/content/llm/) and publish a 308 Permanent Redirect from legacy to
primary endpoints - List only the primary M-URL in the sitemap to
avoid duplication; agents SHOULD follow redirects but rely on sitemap
entries for canonical endpoint discovery - Ensure robots.txt permits
the chosen machine paths as appropriate for your policy
*Caching and CDNs* - Configure intermediaries to honor validators and
serve 304 responses; avoid private on M-URLs and sitemaps to enable
shared caching - Enable compression (gzip or br) for sitemaps and
JSON payloads
*Discovery and Verification* - Prefer discovery via HTML <link
rel="alternate" type="application/json">, HTTP Link headers, or
sitemap entries; agents MUST NOT assume a fixed path - Agents SHOULD
verify the M-URL's canonical link header before processing and skip
ingestion if missing or mismatched
Jurkovikj Expires 8 May 2026 [Page 32]
Internet-Draft Collab-Tunnel November 2025
*Network and WAFs* - Allow the HEAD method (some WAFs block by
default) to enable efficient validation - If using an edge worker/
proxy, ensure required headers (Link, ETag, Cache-Control, Vary) are
preserved or injected consistently
11. Security Considerations
11.1. HTTPS and TLS
M-URLs and sitemaps MUST be served over HTTPS. Agents MUST validate
TLS certificates using platform trust stores and MUST reject invalid
certificates.
11.2. Rate Limiting
Servers MAY expose RateLimit fields ([RFC9448]); agents SHOULD
respect them.
11.3. Content Integrity
The template-invariant fingerprint (SHA-256) provides: - *Tamper
detection*: Agents can verify content integrity - *Cache validation*:
Ensures served content matches expected hash
However, SHA-256 alone does NOT provide: - *Authentication*: Does not
prove publisher identity - *Non-repudiation*: Publisher can deny
serving content
For authenticated content delivery, publishers MAY implement digital
signatures (outside scope of this specification).
11.4. Privacy
Sitemap exposure MAY reveal: - *Content inventory*: All published
URLs - *Modification patterns*: Publishing/update frequency
Publishers SHOULD: - Apply access controls if sitemaps contain
sensitive URLs - Use robots.txt to restrict crawler access if needed
The content field may contain sensitive or personally identifiable
information (PII). Publishers MUST apply access controls to M-URLs
equivalent to those applied to the corresponding C-URLs, and to any
sitemaps listing protected resources (see "Protected Sitemaps" in
MUST Requirements).
For general privacy considerations related to Internet protocols, see
[RFC6973].
Jurkovikj Expires 8 May 2026 [Page 33]
Internet-Draft Collab-Tunnel November 2025
11.5. Denial of Service
11.5.1. Sitemap Abuse
Large sitemaps MAY be used for DoS attacks. Agents SHOULD: -
Implement request rate limiting - Set maximum sitemap size limits
(e.g., 100 MB) - Use streaming JSON parsers for large sitemaps
11.5.2. HEAD vs GET Bandwidth
HEAD requests provide DoS mitigation by enabling validation without
body transfer: - HEAD request: ~500 bytes (headers only) - GET
request: 1-100 KB (full JSON body)
Agents SHOULD use HEAD for validation before GET.
11.6. Injection Surface Reduction
M-URL JSON responses contain only structured text, reducing injection
attack surface compared to HTML: - No <script> tags or inline
JavaScript - No CSS injection vectors - No HTML parsing ambiguities
However, agents MUST: - Validate JSON syntax before processing -
Sanitize content before rendering to users - Treat URLs in JSON as
untrusted input
11.7. Cache Poisoning
Shared caches that ignore validators can serve stale or mixed
content. Publishers SHOULD include Cache-Control: must-revalidate;
agents SHOULD verify the endpoint ETag against cached values and MUST
NOT treat mismatched ETags as fresh.
11.8. Fingerprint Collision and Normalization Variance
SHA-256 fingerprints provide practical collision resistance. The
greater risk is normalization variance. Implementations MUST apply
the baseline normalization consistently; agents MUST NOT infer byte
identity from strong ETags.
11.9. Content Provenance and Origin Authentication (Optional)
For authenticated origin verification of content representations, see
HTTP Message Signatures [RFC9421].
Publishers MAY enhance content authenticity using:
*Content-Digest ([RFC9530]):*
Jurkovikj Expires 8 May 2026 [Page 34]
Internet-Draft Collab-Tunnel November 2025
Provides base64-encoded digest over the representation body.
Content-Digest: sha-256=:X48E9qOokqqrvdts8nOJRJN3OWDUoyWxBf7kbu9DBPE=:
Note: The value is base64 encoding of the binary SHA-256 digest per
[RFC9530].
*HTTP Message Signatures (RFC 9421):* ~~~http Signature:
sig1=:MEUCIQDXlI...; Signature-Input: sig1=("content-digest"
"content-type"); created=1618884473; keyid="key-1" ~~~
These mechanisms are OPTIONAL extensions outside TCT core
requirements.
11.10. Privacy and PII
M-URL JSON MAY contain personally identifiable information (PII) or
sensitive content. Publishers SHOULD: - Apply same access controls
as C-URL HTML - Respect user privacy preferences - Comply with
applicable data protection regulations (GDPR, CCPA, etc.)
Agents SHOULD: - Honor robots.txt and meta robots directives as a
site-wide policy across resources - Respect HTTP authentication
requirements - Not expose cached content beyond publisher-specified
Cache-Control directives
11.11. Access Control
Publishers MAY restrict M-URL access using standard HTTP mechanisms:
- HTTP Authentication (Basic, Bearer, etc.) - IP allowlisting - Rate
limiting per client - Geographic restrictions
Access controls SHOULD be consistent between C-URL and M-URL for the
same resource.
*Authenticated Content Caching:*
Agents that access authenticated M-URLs MUST NOT store the resulting
responses in caches that could be accessed by other unauthenticated
parties. Authenticated content MUST be stored in a private,
credential-scoped cache.
*Authenticated Sitemaps (Informative):* Publishers that protect
M-URLs MAY apply equivalent access controls to sitemap endpoints.
Agents SHOULD obtain and reuse credentials to access protected
sitemaps. Sitemaps MUST NOT disclose protected resources without
equivalent access controls.
Jurkovikj Expires 8 May 2026 [Page 35]
Internet-Draft Collab-Tunnel November 2025
*Security Note*: Authenticated M-URLs MUST NOT leak protected content
via publicly accessible sitemaps. Publishers MUST either exclude
protected resources from sitemaps or apply equivalent access controls
to the sitemap itself.
12. Energy Efficiency Considerations
Summary: Network transmission savings are direct and measurable. The
impact on AI inference energy depends on model architecture and
deployment specifics and is presented for illustrative context.
12.1. Overview
The Collaboration Tunnel Protocol's bandwidth and token reduction
directly translates to significant energy savings across network
infrastructure and AI model inference operations. This section
quantifies the environmental impact of TCT deployment at scale.
12.2. Network Energy Consumption
Data transmission consumes energy at every network layer: routers,
switches, content delivery networks (CDNs), data centers, and end-
user devices. Current estimates for network energy intensity range
from 0.03 kWh/GB (fixed networks) to 0.14 kWh/GB (mobile networks),
with a conservative industry standard of 0.06 kWh/GB for mixed-mode
transmission.
*TCT bandwidth reduction (measured):* - HTML-only retrieval: 103 KB
average - TCT JSON delivery: 17.7 KB average - *Reduction: 85.3 KB
per fetch (83% savings)*
*Energy savings per fetch:* - Bandwidth saved: 85.3 KB = 0.0000853 GB
- Energy saved: 0.0000853 GB x 0.06 kWh/GB = *0.0000051 kWh* (0.0051
Wh) per fetch
*Scaled impact (1 million fetches/day):* - Daily energy savings: 5.1
kWh (5,100 Wh) - Annual energy savings: 1,861.5 kWh - *Carbon
equivalent*: ~930 kg CO2 avoided (assuming 0.5 kg CO2/kWh grid
average)
12.3. AI Inference Impact (Informative Summary)
TCT reduces tokenized payloads by ~86% through normalized JSON
delivery. The impact on inference energy depends on model size,
hardware, batching, and caching; therefore specific kWh figures vary
significantly across deployments. See Appendix "Energy Methodology"
for an illustrative, non-normative scenario and assumptions.
Jurkovikj Expires 8 May 2026 [Page 36]
Internet-Draft Collab-Tunnel November 2025
12.4. Sitemap-First Zero-Fetch Optimization
Beyond per-fetch savings, TCT's sitemap-first verification enables
complete request elimination when content is unchanged.
*Measured skip rate:* 90%+ for unchanged content
For a typical deployment with 1,000 URLs checked daily: - Traditional
crawler: 1,000 full fetches/day - TCT deployment: ~100 fetches/day
(90% skipped via sitemap comparison) - *Additional savings: 900
fetches avoided*
*Combined energy impact:* - Network: Fewer full responses reduce
transmission energy proportionally to bytes avoided - Computation:
Fewer fetches and elimination of local rendering/extraction reduce
crawler CPU/memory work - Inference: Reduced token processing (impact
varies by model and deployment; see Energy Methodology appendix)
12.5. Comparison to Existing Approaches
+================+===========+=========+=====================+
| Method | Avg Size | Tokens | Bandwidth Reduction |
+================+===========+=========+=====================+
| Full HTML page | 350 KB | 47,000 | Baseline |
+----------------+-----------+---------+---------------------+
| HTML body only | 103 KB | 13,900 | 71% |
+----------------+-----------+---------+---------------------+
| AMP HTML | 52 KB | 7,000 | 85% |
+----------------+-----------+---------+---------------------+
| *TCT JSON* | *17.7 KB* | *1,960* | *95%* |
+----------------+-----------+---------+---------------------+
Table 1
Energy impact per fetch depends on network infrastructure, model
architecture, and deployment patterns. See Energy Methodology
appendix for illustrative calculations.
12.6. Cumulative Environmental Impact
TCT's bandwidth reduction (typically 80-90%) and elimination of
client-side rendering translate to measurable energy savings at
scale. Actual impact depends on:
* Deployment scope (number of sites, request volume)
* Network infrastructure efficiency
Jurkovikj Expires 8 May 2026 [Page 37]
Internet-Draft Collab-Tunnel November 2025
* Model provider's hardware and batching strategies
* Grid carbon intensity in serving regions
*Measured improvements:* - 95% smaller payloads (measured across
production deployments) - 90%+ fetch elimination via sitemap-first
logic - 94% reduction in crawler CPU/memory usage
Organizations deploying TCT should measure baseline energy
consumption and monitor post-deployment savings specific to their
infrastructure. See Energy Methodology appendix for example
calculation approaches.
12.7. Relationship to IETF GREEN Working Group
The IETF Getting Ready for Energy-Efficient Networking (GREEN)
Working Group focuses on infrastructure-level energy optimization
through monitoring, measurement, and network-wide traffic
optimization.
TCT complements GREEN's infrastructure focus by addressing
*application-layer efficiency*:
* GREEN targets: Device power consumption, network-wide traffic flow
optimization
* TCT targets: Content delivery efficiency, redundant fetch
elimination, token cost reduction
Together, these approaches create a comprehensive energy reduction
strategy spanning both network infrastructure (GREEN WG) and
application protocols (TCT).
12.8. Recommendations for Implementers
Publishers deploying TCT SHOULD:
1. *Monitor metrics*: Track bandwidth savings, 304 hit rates, and
skip rates
2. *Report impact*: Document energy savings for sustainability
reporting
3. *Optimize aggressively*: Minimize JSON payload size to maximize
efficiency
4. *Promote adoption*: Encourage crawler operators to implement
sitemap-first logic
Jurkovikj Expires 8 May 2026 [Page 38]
Internet-Draft Collab-Tunnel November 2025
Automated agents consuming TCT endpoints SHOULD:
1. *Implement zero-fetch*: Use sitemap hashes to skip unchanged
content
2. *Respect 304 responses*: Honor conditional request discipline
3. *Cache aggressively*: Store ETags and avoid redundant fetches
4. *Measure savings*: Track bandwidth, token, and energy reduction
12.9. Future Work
Potential enhancements for energy optimization:
* *Delta encoding*: Transmit only content changes instead of full
payloads
* *Push notifications*: WebSub or IndexNow integration to eliminate
polling
* *Compression*: Brotli/gzip to further reduce transmission size
* *Edge caching*: CDN-level 304 responses to reduce origin load
13. IANA Considerations
This document has no IANA actions.
Future versions may register:
1. *Well-known URI*: /.well-known/llm-sitemap.json for sitemap
discovery
2. *Profile URI*: Identifying the JSON payload/sitemap format (e.g.,
https://llmpages.org/profile/tct-1)
3. *Link Relation*: If rel="index" with type="application/json"
proves insufficient, a dedicated relation may be registered
Note: The protocol name and URL slug convention (/llm/) is a non-
normative example; implementations choose their own paths.
14. Comparison to Prior Art
Jurkovikj Expires 8 May 2026 [Page 39]
Internet-Draft Collab-Tunnel November 2025
14.1. ResourceSync
ResourceSync [ResourceSync] provides sitemap-based synchronization.
It includes content digests (md5, sha-256) in ResourceSync Change
Lists.
*Key differences:*
1. *Endpoint validator*: ResourceSync does NOT specify using the
digest as endpoint ETag
2. *Handshake*: No bidirectional C-URL <-> M-URL discovery
3. *Zero-fetch*: No specification for skipping endpoint fetch when
sitemap hash matches
4. *Precedence discipline*: No requirement for If-None-Match
precedence
TCT integrates the SAME hash in both sitemap AND endpoint ETag,
enabling zero-fetch optimization.
Unlike ResourceSync, which provides digests over entire
representation files, TCT provides a semantic fingerprint of the
textual content payload, decoupling it from a specific file or HTML
representation.
14.2. AMP
Accelerated Mobile Pages [AMP] provides: - C-URL -> AMP-URL mapping
via <link rel="amphtml"> - Lighter HTML (no JavaScript allowed)
*Key differences:*
1. *Format*: AMP uses HTML; TCT uses JSON
2. *Fingerprinting*: AMP has no content hashing
3. *Sitemap*: AMP sitemaps lack content hashes
4. *Conditional requests*: No specified validator discipline
14.3. XML Sitemaps
Traditional XML sitemaps provide: - URL discovery - <lastmod>
timestamp
*Key differences:*
Jurkovikj Expires 8 May 2026 [Page 40]
Internet-Draft Collab-Tunnel November 2025
1. *Hashes*: XML sitemaps lack content fingerprints
2. *Timestamps*: lastmod insufficient for template changes
3. *Conditional requests*: No integration with HTTP caching
TCT adds content hashes enabling efficient change detection.
15. Implementation Status
[Note to RFC Editor: Remove this section before publication.]
*Reference Implementations:*
* WordPress Plugin: https://github.com/antunjurkovic-collab/trusted-
collab-tunnel
* Python Client: https://github.com/antunjurkovic-collab/collab-
tunnel-python
* Cloudflare Worker: https://github.com/antunjurkovic-collab/
trusted-collab-worker
* Protocol Specification: https://github.com/antunjurkovic-collab/
collab-tunnel-spec
As of October 2025, TCT has been implemented in:
*Publisher implementations:* - WordPress plugin (970 URLs across 3
production sites, 100% compliance) - Cloudflare Worker (edge-based
implementation)
*Measurements:* - HTML-only: 103 KB average (13,900 tokens) - TCT
JSON: 17.7 KB average (1,960 tokens) - *Bandwidth savings: 83%* -
*Token savings: 86%*
*Sitemap-first performance:* - Skip rate: 90%+ for unchanged content
- 304 hit rate: 95%+ on changed content
16. Acknowledgments
Thanks to the WordPress, Cloudflare, and IETF HTTP Working Group
communities for feedback on early drafts.
Test Vector 1: Basic ASCII with Whitespace - Input String: literal
Hello␠␠World\n\t\nTesting (two spaces, newline, tab, newline) -
Normalized String: hello world testing - SHA-256 (hex):
479045cd11cebe841bab15d5ffba3dbac4fed0ca5c4eb74d1102e562a45f4f1f -
Jurkovikj Expires 8 May 2026 [Page 41]
Internet-Draft Collab-Tunnel November 2025
contentHash: sha256-
479045cd11cebe841bab15d5ffba3dbac4fed0ca5c4eb74d1102e562a45f4f1f -
ETag: "sha256-
479045cd11cebe841bab15d5ffba3dbac4fed0ca5c4eb74d1102e562a45f4f1f"
17. References
17.1. Normative References
[RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[RFC9111] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Caching", June 2022,
<https://www.rfc-editor.org/rfc/rfc9111>.
[RFC8288] Nottingham, M., "Web Linking", October 2017,
<https://www.rfc-editor.org/rfc/rfc8288>.
[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/info/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/info/rfc8174>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", July 2002,
<https://www.rfc-editor.org/rfc/rfc3339>.
[RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", December 2017,
<https://www.rfc-editor.org/rfc/rfc8259>.
[UAX15] Unicode Consortium, "Unicode Standard Annex #15: Unicode
Normalization Forms", 2024,
<https://www.unicode.org/reports/tr15/>.
[Unicode-CaseFolding]
Unicode Consortium, "Unicode Case Folding", 2024,
<https://www.unicode.org/versions/Unicode15.1.0/ch03.pdf>.
17.2. Informative References
Jurkovikj Expires 8 May 2026 [Page 42]
Internet-Draft Collab-Tunnel November 2025
[RFC9530] Pardue, L. and R. Polli, "Digest Fields", February 2024,
<https://www.rfc-editor.org/rfc/rfc9530>.
[RFC9421] Backman, A., Richer, J., and M. Sporny, "HTTP Message
Signatures", February 2024,
<https://www.rfc-editor.org/rfc/rfc9421>.
[RFC9448] Polli, R. and A. Martinez, "RateLimit Fields for HTTP",
October 2023, <https://www.rfc-editor.org/rfc/rfc9448>.
[RFC6596] Ohye, M. and J. Kupke, "The Canonical Link Relation",
April 2012, <https://www.rfc-editor.org/rfc/rfc6596>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", July 2013,
<https://www.rfc-editor.org/rfc/rfc6973>.
[RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON
Canonicalization Scheme (JCS)", June 2020,
<https://www.rfc-editor.org/rfc/rfc8785>.
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", May 2019,
<https://www.rfc-editor.org/rfc/rfc8615>.
[ResourceSync]
Open Archives Initiative, "ResourceSync Framework
Specification", May 2017,
<https://www.openarchives.org/rs/1.1/resourcesync>.
[AMP] "Accelerated Mobile Pages (AMP) HTML Specification", n.d.,
<https://amp.dev/documentation/guides-and-
tutorials/learn/spec/amphtml/>.
[WHATWG-HTML]
WHATWG, "HTML Living Standard - Named character
references", n.d.,
<https://html.spec.whatwg.org/multipage/named-
characters.html>.
[XMLSitemaps]
sitemaps.org, "Sitemap XML format", n.d.,
<https://www.sitemaps.org/protocol.html>.
Jurkovikj Expires 8 May 2026 [Page 43]
Internet-Draft Collab-Tunnel November 2025
Appendix A. Example Implementation (WordPress)
This section is informative.
*PHP implementation* (simplified, using Method A - Canonical JSON
Strong-Byte):
function handle_llm_endpoint() {
// Get the current post
$post_id = get_the_ID();
// Build content string (plain text, no HTML)
$title = get_the_title($post_id);
$body = apply_filters(
'the_content',
get_post_field('post_content', $post_id)
);
$body_text = wp_strip_all_tags($body);
// Combine with deterministic separator
$content = $title . "\n\n" . $body_text;
// Generate ETag from content string
$normalized = normalize_text($content);
$hash_hex = hash('sha256', $normalized);
$hash = "sha256-{$hash_hex}";
$etag = "\"{$hash}\""; // Strong ETag (no W/ prefix)
$canonical_url = get_permalink($post_id);
// Check If-None-Match
if (
isset($_SERVER['HTTP_IF_NONE_MATCH'])
&& trim($_SERVER['HTTP_IF_NONE_MATCH']) === $etag
) {
header('HTTP/1.1 304 Not Modified');
header("ETag: {$etag}");
header("Link: <{$canonical_url}>; rel=\"canonical\"");
exit;
}
// Return JSON
header('Content-Type: application/json');
header("ETag: {$etag}");
header("Link: <{$canonical_url}>; rel=\"canonical\"");
header(
'Cache-Control: max-age=0, must-revalidate, '
. 'stale-while-revalidate=60, stale-if-error=86400'
Jurkovikj Expires 8 May 2026 [Page 44]
Internet-Draft Collab-Tunnel November 2025
);
header('Vary: Accept-Encoding');
echo json_encode([
'profile' => 'tct-1',
'canonical_url' => $canonical_url,
'title' => $title,
'content' => $content,
'hash' => $hash
]);
}
// Minimal normalization helper (for Method B implementations)
function normalize_text($text) {
$text = html_entity_decode($text, ENT_QUOTES | ENT_HTML5, 'UTF-8');
if (class_exists('Normalizer')) {
$text = Normalizer::normalize($text, Normalizer::NFKC);
}
if (function_exists('mb_convert_case')) {
$text = mb_convert_case($text, MB_CASE_FOLD, 'UTF-8');
} else {
$text = strtolower($text);
}
$text = preg_replace(
'/[\x00-\x08\x0B-\x0C\x0E-\x1F\x7F-\x9F]/u',
'',
$text
);
$text = preg_replace(
'/[ \t\n\r\f]+/',
' ',
$text
);
return trim($text);
}
Appendix B. Example Sitemap
This section is informative.
Jurkovikj Expires 8 May 2026 [Page 45]
Internet-Draft Collab-Tunnel November 2025
{
"version": 1,
"items": [
{
"cUrl": "https://example.com/article-1/",
"mUrl": "https://example.com/article-1/llm/",
"modified": "2025-10-01T12:00:00Z",
"contentHash": "sha256-abc123..."
},
{
"cUrl": "https://example.com/article-2/",
"mUrl": "https://example.com/article-2/llm/",
"modified": "2025-09-15T08:30:00Z",
"contentHash": "sha256-def456..."
}
]
}
# Normalization Test Vectors (Informative)
This appendix provides test vectors to assist implementers in
validating normalization logic. The final hash MUST be an exact
byte-for-byte match of the normalized string encoded as UTF-8.
Author's Address
Antun Jurkovikj
North Macedonia
Email: antunjurkovic@gmail.com
Jurkovikj Expires 8 May 2026 [Page 46]