]>

antunjurkovic@gmail.com

Web and Internet Transport HTTP, concurrency, ETag, state management 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.

Introduction A single application object is often visible through several HTTP resources or representations. A content-management system might provide an HTML page, a JSON state resource, a Markdown editor, and a form handler, all backed by the same database object. Multiple human and automated clients can construct updates from different views of that object. HTTP already provides optimistic concurrency control through ETag and If-Match . Those fields work when the validator was obtained from a selected representation of the same target resource later modified by the client. Problems arise when an application treats an ETag obtained from one resource as though it were an If-Match condition on a different resource. That changes the target scope of If-Match and is not standard HTTP semantics. AST defines two conformant deployment modes:

• AST Core uses only existing HTTP conditional request fields. Every protected mutation targets the State-Bearing Resource and uses the strong ETag of the State-Bearing Representation selected at that target.
• AST Semantic uses the Semantic Validator extension . A protected mutation can target a projected or otherwise different resource, provided the target positively advertises enforcement of If-Semantic-Match for the same concurrency domain.

Both modes require atomic compare-and-commit behavior. They differ only in which validator and precondition can safely cross representation or resource boundaries.

The Lost-Update Problem Consider an article exposed as HTML at /article/123 and as complete JSON state at /api/article/123.

1. Client A reads one view and changes the article.
2. Client B constructs a different change from an older view.
3. Client B submits its change without a version-specific precondition.
4. The server applies Client B's stale update and overwrites part or all of Client A's work.

AST prevents this outcome by requiring a validator that identifies the state against which the mutation was constructed and by requiring the comparison and state transition to occur as one atomic operation.

Scope AST specifies:

• designation and discovery of a State-Bearing Resource and Representation;
• AST Core use of ETag, If-Match, 412, and 428;
• AST Semantic use of Semantic-ETag and If-Semantic-Match;
• atomicity across all writers in one concurrency domain;
• response behavior, conflict handling, deferred processing, and creation;
• caching, content negotiation, integrity, and security constraints; and
• registration of a link relation for state discovery.

AST does not define an application data model, patch format, merge algorithm, authentication scheme, authorization policy, database transaction mechanism, or non-HTTP binding.

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

Canonical Resource State (CRS)

The authoritative application state whose concurrent modification is protected by AST. The CRS includes every value whose change could make a mutation constructed against an earlier state unsafe.

Concurrency domain

The complete set of CRS values and write paths serialized by one AST precondition. A concurrency domain can be scoped by resource, tenant, principal, language, workflow, or another application boundary.

State-Bearing Representation (SBR)

A selected representation that exposes the complete CRS needed to construct and reconcile protected mutations. Its ordinary strong ETag validates that selected representation.

State-Bearing Resource

The HTTP target resource from which the SBR is selected. AST Core mutations target this resource.

Projected Representation

A representation derived from the CRS but not designated as the SBR. It can omit, transform, summarize, render, or otherwise project state.

Projected Resource

A target resource that provides a Projected Representation or accepts an application-specific action related to the same CRS.

Protected mutation

A state-changing request for which an AST profile requires a version-specific precondition.

Version-specific precondition

An If-Match or If-Semantic-Match value containing at least one explicit validator that identifies a state observed by the client. A wildcard-only condition is not version-specific.

Resource and State Model For each AST concurrency domain, an origin server MUST designate one canonical State-Bearing Resource. That resource selects one SBR that exposes the complete CRS needed for conflict reconciliation. Additional aliases MAY redirect to the canonical State-Bearing Resource, but clients and projected resources need one unambiguous state target. A deployment can use either:

• a dedicated State-Bearing Resource, such as /api/article/123; or
• one URI with content negotiation, provided a request can unambiguously select the SBR for both retrieval and precondition evaluation.

A dedicated State-Bearing Resource is RECOMMENDED because it avoids ambiguity about representation selection on unsafe requests. A TCT M-URL is a Projected Resource by default. It is an AST SBR only when the origin explicitly designates it as such, it losslessly exposes the complete CRS, and it implements all requirements of the chosen AST mode.

Concurrency-Domain Completeness The concurrency domain MUST include all state whose change could invalidate a client's intended mutation. It also MUST include state relevant to the applicable authorization and integrity decisions. If one request atomically modifies several otherwise independent objects, the server MUST either:

• protect a composite concurrency domain that covers all of them; or
• use an application transaction mechanism that prevents partial or stale commits with equivalent safety.

Different principals or audiences MUST use separate domains when they do not observe exactly the same mutation-relevant CRS.

AST Core Profile AST Core is the existing-HTTP-fields deployment mode. It does not change the meaning of ETag or If-Match.

SBR Validator The SBR MUST have a strong ETag as defined by . That ETag validates the exact selected SBR representation. It MUST change whenever the SBR representation data changes. Every CRS change in the concurrency domain MUST produce SBR representation data with a different strong ETag before or atomically with publication of the changed state. The reverse is not required: serializer, schema, profile, or representation metadata changes can require a new strong ETag even when the application regards the CRS as semantically equivalent. A Projected Representation MAY have its own ETag. The SBR ETag MUST NOT be reused as a Projected Representation's ETag unless the selected representation data are identical and all ordinary HTTP strong-validator requirements are satisfied.

Stable SBR Variant A protected AST Core mutation MUST be evaluated against one unambiguously selected SBR variant. The RECOMMENDED deployment is a dedicated SBR URI that serves one media type without Content-Encoding and includes Cache-Control: no-transform. If content negotiation is used at the State-Bearing Resource:

• the client MUST send the request fields needed to select the SBR;
• the server MUST evaluate If-Match against that selected SBR;
• the same selection rules MUST apply when the validator is retrieved and when the mutation is submitted; and
• Vary MUST list every request field used for selection.

An AST Core deployment MUST NOT accept an ETag of one content-coded variant as an If-Match condition on a different selected variant. A deployment that needs representation-independent validation across codings SHOULD implement AST Semantic or expose a dedicated identity-coded State-Bearing Resource.

Core Write Requirement A protected AST Core mutation:

1. MUST target the State-Bearing Resource;
2. MUST select the SBR;
3. MUST contain If-Match with at least one explicit strong entity-tag; and
4. MUST be compared with the current selected SBR using the strong comparison function defined by .

An SBR ETag obtained from one URI MUST NOT be reinterpreted as an If-Match condition on another target URI. A client does not need to retrieve the SBR immediately before every mutation, but it MUST possess the SBR ETag for the state against which the mutation was constructed. The precondition determines whether that belief remains current.

Core Projected-Resource Behavior A Projected Resource that does not implement AST Semantic MUST NOT accept a CRS mutation by treating the SBR ETag as an If-Match condition on the projected target. When such a resource does not support the unsafe method, it SHOULD respond with 405 Method Not Allowed, MUST include an Allow field as required by , and SHOULD include a concurrency-state link to the State-Bearing Resource: ; rel="concurrency-state"; type="application/json" ]]>

AST Semantic Profile AST Semantic extends the profile with the fields defined by . It is intended for protected mutations whose request target is not the State-Bearing Resource or whose selected representation is not the SBR.

Semantic Validator Exposure Every resource from which a client is expected to construct a semantic-mode mutation SHOULD expose Semantic-ETag. Resources in the same concurrency domain MUST expose an equal current semantic validator when they represent the same mutation-relevant CRS. Ordinary ETags remain representation-specific: ; rel="concurrency-state"; type="application/json" ]]> The State-Bearing Resource can expose both its ordinary ETag and the same Semantic-ETag:

Semantic Write Requirement A protected AST Semantic mutation:

1. MUST target a resource and request method for which AST Semantic enforcement is positively advertised;
2. MUST contain If-Semantic-Match with at least one explicit semantic validator;
3. MUST be evaluated in the concurrency domain advertised for that target; and
4. MUST satisfy the comparison, capability, and atomicity requirements of .

A wildcard-only If-Semantic-Match value does not satisfy AST's version-specific precondition requirement. A request MAY also contain ordinary If-Match. When it does, both the representation precondition and semantic precondition MUST succeed.

Capability Advertisement Because an unaware HTTP server can ignore an extension request field, a client MUST NOT rely on If-Semantic-Match unless it has positive knowledge, specific to the target resource and request method, that the target enforces AST Semantic. A conforming AST Semantic deployment MUST make enforcement discoverable for each protected target resource and mutation method. It MUST advertise AST Semantic participation using a profile link relation or application documentation that is equally explicit. The profile link is RECOMMENDED: ; rel="profile" ]]> The profile URI above identifies this exact Internet-Draft revision. Clients MUST NOT assume that a versionless Datatracker URI or a different draft revision is equivalent. A future RFC will define stable RFC-based profile identifiers. The profile link identifies AST Semantic participation but does not by itself enumerate request methods. Method coverage MUST be defined by resource-and-method-specific documentation or another explicit discovery mechanism. A client MUST NOT infer enforcement for another method, resource, or origin from one profile link. AST Core can be advertised similarly: ; rel="profile" ]]> A profile media-type parameter is not defined for application/json by this document and MUST NOT be used as a substitute for the link relation unless the selected media type separately defines such a parameter.

Safe Mutation Processing This section applies to both AST modes. "Required precondition" means If-Match in AST Core and If-Semantic-Match in AST Semantic.

Missing or Inadequate Preconditions For a protected mutation of an existing resource, the server MUST NOT apply the request unless it contains the required version-specific precondition. After authentication, authorization, request syntax, media-type, and other normal validation checks:

• an absent required precondition MUST produce 428 Precondition Required ;
• a wildcard-only value, or a value containing no explicit validator suitable for the selected AST mode, MUST also produce 428; and
• a syntactically valid version-specific condition that does not match MUST produce 412 Precondition Failed.

The 400 Bad Request fallback formerly permitted by this profile is not conformant. A 428 response SHOULD use Problem Details and explain which field is required.

Atomic Compare-and-Commit After normal request validation, evaluation of the required validator, application of the state transition, and publication of the resulting validator MUST occur atomically with respect to every operation capable of changing the same concurrency domain. This requirement applies to HTTP handlers, background workers, migrations, administrator interfaces, message consumers, scheduled jobs, and other write paths. Two concurrent requests MUST NOT both compare successfully against the same old validator and then both commit conflicting transitions. The server MAY implement this requirement with a database compare-and-swap, transactional version column, serializable transaction, lock, version vector, or another mechanism with equivalent behavior.

Successful Responses In AST Core, a successful response can carry the new ordinary ETag only when that ETag correctly describes the selected representation of the target resource under . Typical patterns are: or: For PUT, a server MUST follow the RFC 9110 restriction on sending validators when the received representation was transformed before storage. If a valid new ETag cannot be returned, the client retrieves it with a subsequent GET or HEAD. In AST Semantic, a successful state-changing response SHOULD include the new Semantic-ETag when a current state remains and the principal is authorized to observe it: ; rel="concurrency-state"; type="application/json" ]]> If the response contains a Projected Representation, its ordinary ETag MUST validate that projection, while Semantic-ETag carries the semantic validator. A server MAY use 303 See Other to direct the client to retrieve the current SBR. Content-Location does not rebind an ordinary ETag to another resource, and AST does not define a state-etag Link parameter.

Conflict Responses A 412 Precondition Failed response SHOULD identify the State-Bearing Resource using rel="concurrency-state". Subject to authorization and disclosure policy:

• AST Core MAY include the current SBR ETag when it correctly identifies the current selected representation of the target; and
• AST Semantic SHOULD include the current Semantic-ETag.

; rel="concurrency-state"; type="application/json" { "type": "https://example.com/problems/precondition-failed", "title": "Precondition failed", "status": 412, "detail": "The resource changed after the client constructed its update." } ]]> A validator returned with 412 is advisory and can become stale immediately. A client MUST NOT retry solely by replacing its supplied validator with that value. It MUST first retrieve or otherwise validate the current state and reconcile its intended mutation, unless the operation specification explicitly guarantees that blind retry is safe.

Conflict Resolution After 412, a client can:

• retrieve the current SBR and reapply its intent;
• perform a three-way merge when application semantics make that safe;
• request human or policy-engine intervention; or
• abandon the mutation.

AST does not define merge semantics. A server MAY include authorized conflict context in a Problem Details response, but clients MUST treat it as untrusted and potentially stale.

Deferred Processing A precondition checked only when 202 Accepted is emitted does not protect a state transition committed later. A server performing deferred processing MUST do at least one of the following:

• commit the CRS transition before returning 202, deferring only external side effects;
• reserve or fence the matched version until commit; or
• re-evaluate the expected validator atomically when the deferred transition commits.

A commit-time mismatch MUST prevent the CRS mutation. The operation's status resource or equivalent completion channel MUST report a failed-precondition outcome. The original 202 response cannot be retrospectively changed to 412.

Resource Creation The version-specific precondition requirement applies to mutations of existing concurrency domains. Common creation patterns include:

• POST to a collection resource, with the new resource URI and initial validator returned on success; and
• PUT with If-None-Match: * to create a resource only when no current representation exists at the target URI.

Once created, later protected mutations use AST Core or AST Semantic as advertised. AST does not define an idempotency-key field or replay store; applications can use a separately specified idempotency mechanism.

Read and Cache Behavior

Reading the SBR The State-Bearing Resource MUST support GET. It SHOULD support HEAD when the implementation can provide metadata consistent with the corresponding GET. AST Core clients use ordinary If-None-Match against the State-Bearing Resource. A server returns 304 Not Modified only when the standard HTTP precondition evaluates as specified by . When the corresponding 200 response would contain ETag, the 304 response MUST contain the same current ETag as required by HTTP. Semantic equivalence alone never authorizes a 304; AST Semantic does not change cache revalidation semantics.

Reading Projections Projected Representations use normal HTTP cache validators. A projection's ETag MUST NOT be sent as If-Match to the State-Bearing Resource unless it is also, under ordinary HTTP semantics, a current validator of the selected SBR. AST Semantic projections can expose Semantic-ETag for logical-state observation, but caches continue to use ordinary ETags and standard freshness rules.

Vary and Content Negotiation A response MUST include Vary for every request field used to select its representation, including Accept, Accept-Language, or Accept-Encoding as applicable . AST does not create a new cache key and does not waive ordinary content-negotiation requirements. Range requests do not change validator scope. An origin MAY decline range support for operational reasons, but AST does not require Accept-Ranges: none merely because an SBR is JSON.

Validator Construction

Representation ETags An SBR ETag can be generated using a content hash, a representation revision, or another mechanism satisfying strong-validator requirements. A revision counter used as a strong ETag MUST change whenever the selected SBR representation data changes, including changes caused by serializers, schema profiles, or emitted fields. If a content hash is used, it MUST be computed over the exact representation data validated by the ETag. For a deterministic JSON SBR, an implementation MAY use JCS , but AST does not require JCS when another method satisfies HTTP strong-validator semantics.

Semantic Validators AST Semantic validator construction follows . It is independent of the selected representation's bytes and can therefore remain equal across media types or content codings when they belong to the same concurrency domain.

Stored Validators Storing a validator beside the CRS is permitted, but the storage update alone does not establish conformance. The compare, transition, and validator publication MUST be one atomic operation as described above.

Discovery and Linking

The concurrency-state Link Relation A Projected Resource SHOULD include a concurrency-state link to the canonical State-Bearing Resource: ; rel="concurrency-state"; type="application/json" ]]> The link target identifies the resource from which a client can retrieve the complete state needed to understand and reconcile protected mutations. The link itself does not transfer a validator and does not change the target scope of If-Match. The type target attribute SHOULD identify the expected SBR media type. A client MUST still process the target's actual response according to HTTP and MUST obtain its ordinary ETag from the target in AST Core.

Same-Origin Default Clients SHOULD follow concurrency-state links automatically only when the target is same-origin. Following a cross-origin concurrency-state link requires explicit client policy covering trust, redirects, DNS rebinding, private-network destinations, TLS identity, and credential handling. A client MUST NOT automatically forward Authorization, cookies, client certificates, or other ambient credentials to a newly discovered authority solely because it appears in a concurrency-state link.

Alternate Representations The registered alternate relation MAY be used for navigation among other representations. An alternate link does not imply AST participation or concurrency semantics.

Integrity and Transport ETags and semantic validators are not content-integrity or authentication mechanisms. When payload integrity is required, a sender can use Digest Fields . When message authentication is required, an application can use an appropriate authentication or signature mechanism. Request digest validation is independent of AST precondition evaluation. A server performs authentication, authorization, request syntax and digest validation, and other normal checks before the atomic AST compare-and-commit step.

Non-AST Resources and Fallback A server MAY implement AST for only part of an API. Clients MUST NOT infer AST support for one resource from support on another resource at the same origin. A client that cannot establish AST Core or AST Semantic support MUST NOT assume that a mutation is protected. It can use application documentation, decline the mutation, or use another application-specific safety mechanism.

Security Considerations

Authorization and State Scope The SBR can expose more information than a rendered projection. A server MUST apply authorization appropriate to the complete state and MUST NOT expose fields merely because the user can access a redacted projection. Different authorization views require different concurrency or semantic equivalence domains unless they expose exactly the same mutation-relevant CRS. Authentication and authorization checks MUST precede disclosure of current validators or conflict state.

Cross-Resource and Cross-Origin Confusion An ordinary ETag from one target resource cannot be treated as an If-Match condition on another. AST Semantic permits cross-resource validation only through an explicitly advertised semantic equivalence domain and If-Semantic-Match. Cross-origin discovery can create SSRF, credential-forwarding, redirect, and trust-boundary risks. Same-origin discovery is the default; clients need an explicit cross-origin policy.

Atomicity Failure to serialize every writer in a concurrency domain defeats AST's lost- update guarantee. Operators MUST audit non-HTTP write paths and distributed components, not only the public request handler.

Validator Disclosure and Tracking Validators can reveal update frequency, correlate views, or expose internal revision identifiers. Servers SHOULD use opaque or privacy-preserving construction and separate domains when correlation is sensitive. Validators MUST NOT be treated as authorization tokens.

Blind Retry A new validator does not prove that a stale operation remains semantically valid. Clients that blindly retry after 412 can overwrite intervening changes despite using a current validator. The mandatory reconciliation rule reduces this risk.

Transformation and Intermediaries Intermediaries can transform, compress, strip, or rewrite representation metadata. AST Core deployments SHOULD use a dedicated identity-coded SBR with Cache-Control: no-transform. AST Semantic separates representation ETags from semantic state, but clients still require end-to-end assurance that the origin enforces the semantic precondition.

IANA Considerations IANA is requested to register the following relation in the "Link Relation Types" registry established by .

• Relation Name: concurrency-state
• Description: Refers to the resource that provides the complete authoritative state used to understand and reconcile conditional updates to the context resource.
• Reference: this document
• Notes: The target can expose an ordinary ETag for AST Core and a Semantic-ETag for AST Semantic. The relation does not change the scope or meaning of If-Match.

Before registration, an implementation that needs an extension relation type SHOULD use a URI under a namespace it controls. A mutable Datatracker document URL is not a permanent extension-relation namespace.

Conformance Summary

AST Core Server An AST Core server:

• MUST designate one canonical State-Bearing Resource per concurrency domain;
• MUST expose a strong ETag for the selected SBR;
• MUST require a version-specific If-Match on every protected mutation;
• MUST ensure that the mutation targets and selects the SBR;
• MUST return 428 when the required version-specific condition is absent and 412 when it is false;
• MUST atomically compare, transition, and publish the new validator; and
• MUST NOT reinterpret an SBR ETag as an If-Match condition on another target resource.

AST Semantic Server An AST Semantic server additionally:

• MUST implement ;
• MUST positively advertise enforcement for each protected target and mutation method;
• MUST require a version-specific If-Semantic-Match for cross-representation or cross-resource protected mutations;
• MUST use one complete concurrency domain for equal semantic validators; and
• SHOULD return the resulting Semantic-ETag after a successful transition.

AST Client An AST client:

• MUST possess the validator for the state against which its mutation was constructed;
• MUST use If-Match only at the SBR target in AST Core;
• MUST use If-Semantic-Match only after positive capability discovery in AST Semantic;
• MUST NOT use wildcard-only conditions as AST version evidence; and
• MUST reconcile state after 412 rather than blindly substituting a returned validator.

Changes Since -01 This revision:

• separates AST Core and AST Semantic conformance modes;
• restricts AST Core If-Match to the selected SBR at the request target;
• integrates Semantic-ETag and If-Semantic-Match for cross-resource writes;
• requires resource-and-method-specific capability signaling for semantic preconditions;
• requires 428 rather than a 400 fallback;
• rejects wildcard-only conditions as AST version evidence;
• requires atomic compare-and-commit across every writer;
• corrects deferred 202 processing;
• removes the state-etag Link parameter and the 204 plus Content-Location ETag pattern;
• names the state-discovery relation concurrency-state;
• prohibits blind retry based only on a validator returned with 412;
• distinguishes semantic validators from ordinary cache validators and digest fields;
• makes same-origin concurrency-state discovery the default; and
• clarifies that a TCT M-URL is a projection unless explicitly designated as a complete AST SBR.

References Normative References 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. 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. 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. This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations. [STANDARDS-TRACK] This document defines a "problem detail" to carry machine-readable details of errors in HTTP response content to avoid the need to define new error response formats for HTTP APIs. This document obsoletes RFC 7807. 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. Informative References This document specifies the Collaboration Content Transfer (TCT) Protocol, an HTTP-based method for efficient, verifiable delivery of web content to automated agents. TCT defines a JSON envelope that encapsulates resource content in negotiated text-based formats (such as Markdown or plain text) together with canonical metadata. It uses bidirectional URL discovery between human-facing and machine-facing URLs, JSON sitemaps, strong ETag validators, and conditional requests to reduce bandwidth while preserving semantic structure and canonical identity. 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. 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.

Appendix A. AST Core Example

Read the SBR ; rel="profile" {"id":123,"status":"published","title":"Example"} ]]>

Conditional Mutation

Projected Target Rejection ; rel="concurrency-state"; type="application/json" ]]>

Appendix B. AST Semantic Example

Read a Projection ; rel="concurrency-state"; type="application/json" Link: ; rel="profile" ]]>

Conditional Mutation Through the Projected Target ; rel="concurrency-state"; type="application/json" ]]>

Conflict ; rel="concurrency-state"; type="application/json" { "type": "https://example.com/problems/precondition-failed", "title": "Precondition failed", "status": 412, "detail": "Retrieve the current state and reconcile the intended change." } ]]>

Appendix C. Single-URI Core Deployment A single URI can serve both HTML and the SBR by content negotiation, but the protected mutation must unambiguously select the same SBR variant: If the server cannot unambiguously select the SBR for the unsafe request, it MUST NOT apply AST Core If-Match semantics to that request. A dedicated SBR URI is therefore preferred.

Appendix D. Canonicalization Test Vector For deployments that choose JCS and SHA-256 for the SBR representation: Input JSON: JCS form: SHA-256 hexadecimal: Base64-encoded digest example: