The Collaboration Content Transfer (TCT) Protocol

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;¶

• 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.¶

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"

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

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

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

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

• 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.¶

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

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:¶

{
  "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;¶

• 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.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.¶

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

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

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

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

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

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

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

[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

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

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

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"