]>

North Macedonia antunjurkovic@gmail.com

Web and Internet Transport HTTP, content delivery, automated agents, ETag, JSON sitemap This document specifies the Collaboration Content Transfer (TCT) Protocol, an experimental HTTP profile for efficient delivery of publisher-selected web content to automated clients. TCT defines a deterministic JSON representation at a machine-facing URL, bidirectional discovery between human-facing and machine-facing resources, JSON sitemaps containing representation-validator hints, and conditional request behavior using ordinary strong ETags. TCT preserves standard HTTP validator scope: an M-URL ETag identifies the exact selected M-URL representation. Optional Semantic Validators can correlate the logical state of human-facing and machine-facing representations, but are not required by TCT and do not replace ordinary cache validators. TCT does not define authorization, licensing, content-use policy, or mutation semantics.

Introduction Automated clients such as search engines, archives, monitoring systems, aggregators, retrieval systems, and AI-assisted tools often need the substantive content of a web resource rather than its complete browser presentation. Fetching and parsing full HTML pages can repeatedly transfer templates, navigation, advertising, scripts, and other material that is not needed for that task. Many publishers already provide JSON APIs, feeds, Markdown views, or crawler-specific endpoints. Those mechanisms differ in discovery, envelope shape, canonical identity, and validator behavior. TCT defines a narrow experimental profile that combines:

• a human-facing canonical URL (C-URL);
• a machine-facing deterministic JSON URL (M-URL);
• bidirectional Web links between those resources;
• an M-Sitemap listing C-URL/M-URL mappings and identity-representation ETag hints; and
• normal HTTP conditional requests for target-resource validation.

The protocol is additive. Non-TCT clients ignore the additional resources and links. TCT-aware clients can reduce repeated M-URL transfers while retaining ordinary HTTP cache semantics. The earlier name "Collaboration Tunnel" does not indicate network-layer tunneling. It describes a publisher-provided content channel alongside the human-facing web representation.

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 when, and only when, they appear in all capitals, as shown here.

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.

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.

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.

Protocol Overview A typical flow is:

1. A client retrieves an origin resource and discovers an M-Sitemap through a Link field or an HTML link element.
2. The client retrieves and validates the M-Sitemap profile and structure.
3. For each item, the client learns the C-URL, M-URL, and optional identity ETag hint.
4. The client retrieves an M-URL or conditionally revalidates a cached representation with If-None-Match.
5. The M-URL links back to the C-URL with rel="canonical".

When a fresh or revalidated M-Sitemap contains an ETag hint equal to a cached identity M-URL ETag, a client MAY reuse its cached M-URL without another request. That reuse has freshness no stronger than the M-Sitemap response and the publisher's catalog-update behavior. A client requiring target-resource validation performs a conditional request to the M-URL under normal HTTP cache semantics . A fresh intermediary can satisfy that request without contacting the origin.

TCT Profile Identifiers This revision defines three exact profile identifiers:

• M-URL profile: https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile
• M-Sitemap profile: https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-profile
• M-Sitemap Index profile: https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-sitemap-index-profile

These identifiers refer to this exact Internet-Draft revision. Clients MUST NOT treat a versionless Datatracker URI, another revision, or a short string such as tct-1 as automatically equivalent. A future RFC is expected to replace these identifiers with stable RFC-based profile URIs.

Discovery

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 on a successful response from the origin root or another documented entry resource: ; 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: ]]> 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.

C-URL to M-URL Discovery A participating C-URL SHOULD advertise the M-URL using rel="alternate" and type="application/json": ; rel="alternate"; type="application/json" ]]> or, in HTML: ]]> 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.

M-URL to C-URL Discovery An M-URL response MUST contain a canonical link to its C-URL: ; rel="canonical" ]]> It MUST also advertise the M-URL profile using the registered profile relation : ; 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.

URI Requirements The canonical_url, cUrl, mUrl, and sitemap-index url values MUST be absolute https or http URIs conforming to . 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.

TCT M-URL Profile An M-URL is an ordinary HTTP resource serving a deterministic JSON envelope. It is read-oriented; TCT does not define unsafe-method behavior at an M-URL.

Response Requirements An identity M-URL response:

• MUST use Content-Type: application/json;
• MUST be valid JSON ;
• 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: 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.

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 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 are expected. A producer MUST NOT claim a media type whose syntax the content string does not follow.

Example before canonical serialization:

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

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.

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.

Deterministic JSON and TCT ETags All identity TCT JSON representations -- M-URLs, M-Sitemaps, and M-Sitemap Indexes -- use the same JCS and SHA-256 ETag algorithm in this section.

JCS Serialization The producer MUST serialize the complete JSON value using JSON Canonicalization Scheme (JCS) . 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.

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 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: ; rel="canonical" Link: ; rel="profile" ]]>

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.

Digest Fields For an identity representation, a server SHOULD include Content-Digest with sha-256 according to . 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 . TCT does not redefine those rules.

TCT M-Sitemap Profile An M-Sitemap is a JSON catalog of TCT resources.

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.

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 supplied as scheduling metadata. It is not an HTTP validator and does not replace ETag revalidation.

Example before JCS serialization: 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.

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.

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 . When the values differ, or the item omits etag, the client SHOULD issue a conditional M-URL request using its cached M-URL ETag.

TCT M-Sitemap Index Profile Large origins MAY divide the catalog into multiple M-Sitemaps and advertise an M-Sitemap Index.

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

Client Processing

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.

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

Conditional GET M-URLs MUST process If-None-Match according to . 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 .

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.

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.

Caching and Operational Considerations M-URLs, M-Sitemaps, and M-Sitemap Indexes are ordinary cacheable resources governed by . Publishers select Cache-Control according to update frequency and sensitivity. Catalogs SHOULD have short enough freshness lifetimes to make their hints useful, while avoiding unnecessary revalidation. A shared cache or CDN:

• MUST preserve correct ETag semantics for each selected representation;
• MUST NOT reuse a strong ETag across non-identical coded and identity representations;
• MUST honor Vary: Accept-Encoding when coding selection depends on that field; and
• MUST NOT rewrite TCT JSON without generating the corresponding new validator.

Publishers SHOULD give M-Sitemaps and indexes their own strong ETags so clients can revalidate large catalogs without retransferring them. TCT does not require atomic publication across several HTTP resources. A client can observe a catalog snapshot concurrent with resource updates. The bounded skip semantics above and M-URL validation under normal HTTP cache semantics provide the fallback behavior.

Relationship to Semantic Validators and AST TCT defines read-oriented representations and ordinary representation validators. It does not define cross-representation concurrency. An origin implementing Semantic Validators for HTTP MAY include the same Semantic-ETag on a C-URL and M-URL when both belong to the same semantic equivalence domain: The fields remain independent:

• ETag changes whenever the exact selected M-URL representation changes.
• Semantic-ETag changes whenever the shared logical state changes under the origin-defined domain.

A TCT M-URL is not an AST State-Bearing Representation merely because it is JSON, deterministic, or machine-oriented. It becomes an AST SBR only when it losslessly exposes the complete Canonical Resource State, is explicitly advertised as an AST SBR, and implements the applicable AST requirements . TCT clients MUST NOT send If-Semantic-Match merely because a response carries Semantic-ETag; positive capability knowledge is required by the Semantic Validator specification.

Security Considerations

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 or another appropriate mechanism.

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.

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.

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.

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.

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.

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.

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.

Privacy Considerations M-Sitemaps can reveal site structure, update cadence, language variants, and content identifiers. Publishers SHOULD omit sensitive resources and protect private catalogs. Clients SHOULD minimize unnecessary request identifiers and follow applicable privacy policy.

IANA Considerations This document requests no new IANA registrations. It uses registered HTTP fields and link relations and identifies this experimental revision with exact URI-valued profiles. A future standards-track version can request dedicated media types, a well-known discovery URI, or other registrations if implementation experience shows that they improve interoperability.

Changes Since -02 This revision:

• restores all main section and subsection headings;
• replaces short, ambiguous profile strings with exact URI-valued profiles;
• removes the undefined profile Link target attribute from discovery;
• removes charset from application/json response examples;
• adds URI, BCP 47, duplicate-name, unknown-member, and size-processing rules;
• removes the optional Unicode case-folding and whitespace-normalization profiles from TCT core;
• requires the served identity body to be the same JCS bytes used for ETag generation;
• defines catalog ETag hints as identity-representation validators and requires Accept-Encoding: identity when clients use them conditionally;
• requires every catalog ETag hint to use the exact TCT SHA-256 ETag form;
• gives M-Sitemaps and indexes their own ETags and conditional-request behavior;
• narrows "zero-fetch" to a skip optimization with catalog-bounded freshness and distinguishes cache validation from successful origin validation;
• removes the fixed one-minute refetch rule in favor of HTTP freshness, Retry-After, and backoff;
• clarifies that robots rules are not access control;
• adds cross-origin and SSRF requirements; and
• clarifies optional Semantic Validator correlation and the rule that an M-URL is not an AST SBR by default.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content. This document is not an Internet Standards Track specification; it is published for informational purposes. This specification defines the 'profile' link relation type that allows resource representations to indicate that they are following one or more profiles. A profile is defined not to alter the semantics of the resource representation itself, but to allow clients to learn about additional semantics (constraints, conventions, extensions) that are associated with the resource representation, in addition to those defined by the media type and possibly other mechanisms. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. Federal Information Processing Standard, FIPS This document defines HTTP fields that support integrity digests. The Content-Digest field can be used for the integrity of HTTP message content. The Repr-Digest field can be used for the integrity of HTTP representations. Want-Content-Digest and Want-Repr-Digest can be used to indicate a sender's interest and preferences for receiving the respective Integrity fields. This document obsoletes RFC 3230 and the Digest and Want-Digest HTTP fields. This document defines a date and time format for use in Internet protocols that is a profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Informative References This document registers the text/markdown media type for use with Markdown, a family of plain-text formatting syntaxes that optionally can be converted to formal markup languages such as HTML. This document defines the Semantic-ETag HTTP response field and the If-Semantic-Match HTTP request field. Unlike the standard ETag field, which identifies a selected representation, Semantic-ETag identifies a server-defined semantic state within an explicitly scoped semantic equivalence domain. If-Semantic-Match enables origin servers to perform representation-independent optimistic concurrency control when different HTTP resources or representations expose the same logical state. This document does not update or replace the semantics of ETag, If- Match, or HTTP cache validation defined by RFC 9110. HTTP applications frequently expose one logical object through several representations or resources. Ordinary HTTP entity tags identify selected representations; they do not, by themselves, provide a conditional-update mechanism spanning different request targets. This document specifies Agentic State Transfer (AST), an HTTP profile for preventing lost updates to shared application state. AST Core requires a client to mutate the State-Bearing Resource using the strong ETag of its State-Bearing Representation and the standard If- Match field. AST Semantic uses Semantic-ETag and If-Semantic-Match when a protected mutation targets a different resource or representation in the same concurrency domain. The profile also defines state discovery, atomic compare-and-commit behavior, conflict handling, deferred processing, caching constraints, and security requirements. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange.

Appendix A. Complete Discovery and Fetch Example

Discover the Catalog ; rel="index"; type="application/json" ]]>

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. ; 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} ]]>

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. ; rel="canonical" Link: ; 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"} ]]>

Revalidate the M-URL

Appendix B. Catalog Skip Example A client has cached the identity M-URL with ETag "sha256-c17d360f48654afc28838ab115ad4bcceae5a429130637b7706e35502bb7f17b". It retrieves or successfully revalidates the M-Sitemap and observes the equal item etag value without HTTP quotes. The client can either:

• skip the M-URL request and accept freshness bounded by the M-Sitemap and publication behavior; or
• issue the conditional M-URL request above when target-resource validation is required, adding Cache-Control: no-cache to request successful origin validation.

The skip decision is an optimization, not a stronger freshness guarantee than HTTP provides for the M-Sitemap response.

Appendix C. Canonicalization and ETag Test Vector Input JSON value: Exact JCS UTF-8 text: SHA-256 hexadecimal: Resulting ETag:

Acknowledgments Thanks to reviewers and implementers who identified the need to preserve ordinary HTTP validator scope, separate semantic state from representation identity, define catalog-bounded skip semantics, and simplify the experimental protocol surface.