{"canonical_url":"https://generic-tct.llmpages.org/content/publishing-machine-content-with-tct","content":"Publishing Machine-Facing Content with TCT\n\nCollaboration Content Transfer (TCT) gives a publisher a precise way to pair a human-facing web resource with a deterministic machine-facing representation while keeping ordinary HTTP discovery, caching, and validator semantics intact.\n\nThe publishing problem\n\nA modern web page is usually designed for people. Its HTML can include navigation, typography, responsive layout, analytics hooks, accessibility structure, related-content modules, and application code. Those features are valuable in a browser, but an automated client often needs the publisher's main content and a reliable way to determine whether that content has changed.\n\nMachine clients can extract text from ordinary HTML, and TCT does not prohibit that. The problem is that extraction policy then belongs to every client. Different clients can select different parts of the same page, repeat expensive rendering work, or lose track of which derived bytes they previously processed. A publisher-controlled machine representation makes that selection explicit and gives it its own stable HTTP identity.\n\nTwo resources with different jobs\n\nTCT calls the human-facing canonical resource the C-URL and the machine-facing JSON resource the M-URL. The C-URL remains the normal page for browsers, search engines, and clients that do not use TCT. The M-URL is an ordinary HTTP resource whose representation is selected and published by the same origin.\n\nThe M-URL does not replace the C-URL, and TCT does not claim that the two byte sequences are interchangeable. Their media types, layout, and representation metadata can differ. What TCT adds is an explicit publisher-declared relationship, a deterministic JSON envelope, and validator rules that let a client reason about the exact M-URL bytes it cached.\n\nThe C-URL serves the human experience and remains independently usable.\nThe M-URL serves a publisher-selected machine representation.\nEach selected representation keeps its own HTTP metadata and validator scope.\nThe mapping is discoverable instead of being guessed from a conventional path.\n\nDiscovery without path guessing\n\nA TCT publisher exposes an M-Sitemap or an M-Sitemap Index and makes the catalog discoverable. An HTTP Link field can advertise the catalog from an origin entry resource. A participating C-URL can also advertise its M-URL with an alternate link, while the M-URL links back to the C-URL and identifies the applicable TCT profile.\n\nThe M-Sitemap lists explicit C-URL and M-URL pairs. This matters operationally because a client does not need to invent a suffix, rewrite a path, or assume that every page participates. A publisher can choose which resources are exposed, divide a large catalog into bounded parts, and change a mapping through a newly validated catalog response.\n\nExact representation identity\n\nAn identity TCT JSON response is serialized deterministically and carries a strong ETag derived from its exact bytes. If any selected representation byte changes, the strong ETag changes. Two successful identity responses with the same TCT ETag therefore have identical content octets.\n\nThis is ordinary HTTP representation validation, not a new cache protocol. A client that has an M-URL response can send its stored ETag in If-None-Match. A matching current representation produces 304 Not Modified and no response body. A stale condition produces 200 OK with the current representation and its current ETag.\n\nThe validator identifies the M-URL representation selected by that request. It does not authenticate the publisher, prove that the content is true, or assert that an independently encoded representation has the same meaning. Authentication, authorization, signatures, and policy remain separate concerns.\n\nCatalog hints and bounded freshness\n\nAn M-Sitemap item can carry the opaque value of the current identity M-URL ETag. That value is a hint copied into the catalog when the catalog representation is generated. The authoritative validator is still the ETag returned by the M-URL itself.\n\nIf a client has a cached identity M-URL and a fresh or successfully revalidated catalog contains the same hint, the client can reuse its cached M-URL without another target request. The optimization is deliberately bounded. Its freshness is no stronger than the catalog response, the publisher's catalog-update behavior, and the normal race after catalog generation.\n\nA client that requires target validation at the latest possible instant sends a conditional request to the M-URL. TCT therefore supports both a catalog-level scheduling optimization and direct resource revalidation without confusing the two.\n\nTransformation and fidelity\n\nThe publisher decides how source material becomes the M-URL representation. A WordPress implementation might extract saved post blocks, preserve headings and list items, remove presentation markup, and place the resulting text in a JSON envelope. Another origin might generate the envelope directly from a content model.\n\nTCT does not claim that every transformation is lossless. A summary, normalization step, or format conversion can omit information that exists at the C-URL. Material transformation choices should be documented so clients understand the publisher's representation. For evaluation, the human and machine fixtures should contain the same substantive article before their transfer sizes are compared.\n\nDelivery through intermediaries\n\nA CDN or reverse proxy can deliver TCT resources, but it must preserve correct HTTP representation semantics. If an intermediary transforms the representation bytes, the transformed selected representation needs its own strong validator. Reusing the identity ETag for different coded or transformed bytes would make the validator false.\n\nThe reference deployment uses an origin response with deterministic identity bytes and a Cloudflare Worker that preserves those bytes and their strong ETag. Requests that forbid the identity content coding fail closed. Vary and no-transform metadata make the selected-representation boundary explicit, while edge and direct-origin checks verify that the observed bytes remain equal.\n\nFailure behavior matters\n\nUseful testing includes more than a successful 200 response. A stale conditional request must return the new representation rather than incorrectly producing 304. A missing M-URL must remain missing. An item hint that does not match the cached authoritative ETag must not authorize local reuse. A changed mapping must invalidate the old C-URL/M-URL binding, and a client must apply its normal origin and security policy before following a replacement URL.\n\nThese cases protect the value of the fast path. Skipping work is only safe when the identity and freshness predicates that justify the skip are actually satisfied.\n\nMeasuring a TCT deployment\n\nA credible measurement starts with representative and content-equivalent fixtures. Comparing a fully rendered page with an empty placeholder, or comparing unrelated content, can produce a mathematically correct percentage that says nothing useful about the protocol.\n\nResponse-body bytes, request counts, edge requests, origin requests, origin processing time, and client-observed latency are different quantities. They should be reported separately. A 304 response can remove response-body transfer without removing the client-to-edge request. A catalog check can replace several target checks only when the client accepts the catalog's bounded freshness. CDN scheduling can reduce crawler requests, but that is a separate mechanism and should not be attributed to TCT.\n\nThe most useful report states the exact URLs, content basis, request sequence, validator outcomes, and unavailable measurements. It also keeps protocol correctness results separate from performance observations.\n\nA practical implementation sequence\n\nA publisher can begin with one real article. First, define the C-URL and a deterministic M-URL representation containing the same substantive material. Second, compute the M-URL's strong ETag from the exact identity bytes. Third, publish a catalog entry containing the two URLs and the current identity ETag hint. Fourth, expose discovery links and verify GET, HEAD, conditional GET, stale conditions, and missing-resource behavior through every selected delivery path.\n\nA client begins by discovering and validating the catalog. It stores the M-URL bytes together with the authoritative response ETag. On a later pass, it either revalidates the target directly or uses a fresh catalog hint under the bounded reuse rule. If the representation changed, the client processes the new bytes and stores the new validator.\n\nScope and limits\n\nTCT is a read-oriented content-publication profile. It does not define mutation, conflict resolution, payment, crawler identity, authorization, or a universal machine-content schema. Those concerns can be composed with TCT, but they are not implied by the presence of an M-URL or catalog.\n\nThe current work is an individual Experimental Internet-Draft and its implementations are experimental. The useful claim is narrow: a publisher can expose an explicit machine representation with deterministic bytes, discoverable mappings, and correct ordinary HTTP validators. Broader adoption, operational savings, and interoperability require evidence from representative deployments and independent implementations.\n\nConclusion\n\nTCT keeps the web page and the machine representation as first-class HTTP resources with different jobs. The publisher controls the mapping and transformation, the M-URL has exact representation identity, and clients can choose between direct conditional validation and a catalog-bounded reuse optimization.\n\nThat design is intentionally modest. It does not ask a client to trust a filename convention or a nonstandard cache. It gives publishers and automated clients a concrete surface that can be tested with normal HTTP messages, including the failure cases that determine whether an optimization is safe.","content_media_type":"text/plain; charset=utf-8","lastModified":"2026-08-15T20:00:00+00:00","llm_url":"https://generic-tct.llmpages.org/tct/m/publishing-machine-content-with-tct","profile":"https://www.ietf.org/archive/id/draft-jurkovikj-collab-tunnel-03.html#tct-m-url-profile","published":"2026-08-15T20:00:00+00:00","slug":"publishing-machine-content-with-tct","summary":"Collaboration Content Transfer (TCT) gives a publisher a precise way to pair a human-facing web resource with a deterministic machine-facing representation while keeping ordinary HTTP discovery, caching, and validator semantics intact.","title":"Publishing Machine-Facing Content with TCT","word_count":1451}