{ "model": { "rank": 2773, "code": "thing-q8777", "model_id": "vr.tr.http", "name": "HTTP", "purpose": "Enable an AI agent to recognise HTTP interactions, assess their semantic and operational state, and determine which requests, retries, reuse and forwarding actions are justified.", "family": "Thing Registry", "category": "Information and virtual systems", "status": "research-draft", "kind": "thing", "plane": "INF", "domain": "INF.KNW", "industry": "", "version": "", "url": "/models/thing/q8777/", "tier": 2, "score": 97, "payload": { "layer": "wikidata", "aliases": [ "Secure Hypertext Transfer Protocol", "HTTPS" ], "aliasCount": 2, "merged": 2, "knownIn": 97, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q8777", "url": "https://www.wikidata.org/wiki/Q8777", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T11:43:06Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.01174224, "turns": 1, "seconds": 128.7, "error": null }, "codex": { "seconds": 78.5, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a07ba9-6cca-71d3-9b18-6670f8750092\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: HTTP\nRegistry id: vr.tr.http\nPlane / domain: INF / INF.KNW\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\nA Vercy model s" } } }, "metaModel": { "id": "THING-Q8777", "registryId": "vr.tr.http", "name": "HTTP", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "INF.KNW" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q8777/", "model": { "registry_id": "vr.tr.http", "name": "HTTP", "purpose": "Enable an AI agent to recognise HTTP interactions, assess their semantic and operational state, and determine which requests, retries, reuse and forwarding actions are justified.", "definition": "HTTP is a generic, stateless, application-layer request/response protocol that transfers representations of URI-identified resources using self-descriptive messages, with version-specific mappings onto TCP (HTTP/1.x), a binary framed layer over TLS/TCP (HTTP/2), or QUIC (HTTP/3), as defined by the IETF HTTP specifications centred on RFC 9110.", "scope_statement": "This model owns HTTP as an application-level protocol: shared request and response semantics, representations, caching, intermediaries, version-specific messaging, and the evidence needed to judge a particular HTTP interaction.", "in_scope": [ "Request methods, target URIs, fields and response status semantics", "Representation metadata, content negotiation and message content", "Conditional requests, partial transfers and cache reuse", "HTTP versions, message framing, streams and intermediary behaviour", "Protocol-level evidence governing authentication, redirection, retries and completion" ], "out_of_scope": [ "Application-specific resource schemas, business rules and transaction guarantees", "DNS resolution and domain ownership", "TCP and QUIC transport internals", "TLS cryptography, certificate lifecycle and trust administration", "Browser document rendering, JavaScript execution and browser policy configuration", "Service deployment, infrastructure capacity and organisational access governance" ], "distinguishing_features": [ "An interaction uses HTTP method and status semantics; carrying bytes over TCP or QUIC alone does not make it HTTP.", "An HTTPS URI identifies HTTP communication secured through TLS, rather than a separate application semantics model.", "HTTP can carry many representation formats; HTML or JSON content alone does not identify the protocol.", "HTTP does not require REST architectural constraints, and a REST claim does not establish which HTTP semantics an API honours.", "HTTP/1.1, HTTP/2 and HTTP/3 share core semantics while differing in message encoding and connection or stream handling; textual start lines are not a universal recognition test." ], "characteristics": [ { "name": "Observed HTTP version", "kind": "category", "unit_or_values": "HTTP/1.0 | HTTP/1.1 | HTTP/2 | HTTP/3 | other | unknown; recorded per hop", "why_it_matters": "Determines applicable messaging rules without assuming that every intermediary uses the same version." }, { "name": "Request method", "kind": "category", "unit_or_values": "Case-sensitive method token with known, extension or unknown semantics", "why_it_matters": "Constrains expected effects, content interpretation, caching and retry decisions." }, { "name": "Target resource", "kind": "relation", "unit_or_values": "Target URI, its scheme and authority, and its relationship to the contacted peer", "why_it_matters": "Separates the resource being addressed from proxies and other participants carrying the request." }, { "name": "Response status", "kind": "category", "unit_or_values": "Observed three-digit status code, informational or final role, and known or unknown meaning", "why_it_matters": "Supports protocol-level interpretation without treating a successful status as proof of a business outcome." }, { "name": "Exchange completion", "kind": "state", "unit_or_values": "Not sent | in progress | informational response received | final response incomplete | complete | failed | outcome unknown", "why_it_matters": "Distinguishes a complete response from a request whose server-side effects remain uncertain." }, { "name": "Representation description", "kind": "category", "unit_or_values": "Declared media type, content coding, language and presence or absence of relevant metadata", "why_it_matters": "Controls interpretation and negotiation while preserving uncertainty about undeclared or inconsistent content." }, { "name": "Cache reuse eligibility", "kind": "state", "unit_or_values": "Not evaluated | reusable while fresh | validation required | stale reuse permitted under recorded conditions | reuse prohibited", "why_it_matters": "Prevents reuse decisions based only on possession of an earlier response." }, { "name": "Freshness lifetime and current age", "kind": "measurement", "unit_or_values": "Seconds, with calculation inputs and observation time", "why_it_matters": "Provides evidence for freshness decisions rather than relying on a timestamp alone." }, { "name": "Retry justification", "kind": "state", "unit_or_values": "Not assessed | justified by method and failure evidence | justified by an application guarantee | unjustified | uncertain", "why_it_matters": "Makes duplicate-effect risk explicit when the first request's outcome is unknown." } ], "affordances": [ "Interpret a request and its response sequence using the applicable HTTP semantics.", "Construct a request with suitable method, target, negotiation fields and preconditions.", "Assess whether a failed or interrupted request may be retried and record the justification.", "Decide whether a stored response may be reused, validated or replaced.", "Evaluate a redirect or authentication challenge before choosing a follow-up request.", "Diagnose protocol inconsistencies across message framing, intermediaries and version boundaries." ] }, "sources": [ { "id": "rfc9110", "title": "RFC 9110: HTTP Semantics", "url": "https://www.rfc-editor.org/rfc/rfc9110", "what_it_supports": "Normative definition of HTTP as a protocol family, methods, status codes, fields, and resource/representation model", "url_status": "blocked" }, { "id": "rfc9112", "title": "RFC 9112: HTTP/1.1", "url": "https://www.rfc-editor.org/rfc/rfc9112", "what_it_supports": "HTTP/1.1 message syntax, persistent connections, and chunked transfer coding", "url_status": "blocked" }, { "id": "rfc9113", "title": "RFC 9113: HTTP/2", "url": "https://www.rfc-editor.org/rfc/rfc9113", "what_it_supports": "HTTP/2 binary framing, streams, and HPACK; ALPN token h2", "url_status": "blocked" }, { "id": "rfc9114", "title": "RFC 9114: HTTP/3", "url": "https://www.rfc-editor.org/rfc/rfc9114", "what_it_supports": "HTTP/3 mapping onto QUIC; distinction from the QUIC transport itself", "url_status": "blocked" }, { "id": "rfc2818", "title": "RFC 2818: HTTP Over TLS", "url": "https://www.rfc-editor.org/rfc/rfc2818", "what_it_supports": "HTTPS as HTTP over TLS, https URI scheme, and default port 443", "url_status": "live" }, { "id": "fetch", "title": "Fetch Standard", "url": "https://fetch.spec.whatwg.org/", "what_it_supports": "Browser-facing HTTP client behaviour, CORS, and redirects as implemented on the Web", "url_status": "live" }, { "id": "wikidata-q8777", "title": "Hypertext Transfer Protocol (Q8777)", "url": "https://www.wikidata.org/wiki/Q8777", "what_it_supports": "Stable public identifier for the protocol as a catalogue item", "url_status": "live" } ], "structure": { "bundles": [ { "id": "request-intent-and-resource", "name": "Request intent and resource", "description": "Records which resource an HTTP request addresses and what its method asks the recipient to do.", "rationale": "An agent needs a grounded interpretation of request intent before judging effects or issuing a follow-up.", "layers": [ { "id": "target-and-authority", "name": "Target and authority", "description": "Distinguishes the target URI and authority from the peer or intermediary receiving the message.", "findings": [ { "id": "effective-request-target", "name": "Effective request target", "description": "Record the target URI and the evidence used to establish its scheme, authority and resource identifier.", "questions": [ { "text": "Which URI is targeted, and how do the request-target form, authority fields or pseudo-fields establish it?", "kind": "definition", "id": "effective-request-target-q01" }, { "text": "Is the contacted peer the origin server, a forward proxy, a gateway or a tunnel endpoint?", "kind": "boundary", "id": "effective-request-target-q02" } ] } ] }, { "id": "method-and-effect", "name": "Method and effect", "description": "Separates standard method properties from observed or documented application behaviour.", "findings": [ { "id": "method-semantics-and-guarantees", "name": "Method semantics and guarantees", "description": "Record the method's defined semantics, safety and idempotency, together with evidence of any application-specific guarantees or deviations.", "questions": [ { "text": "What does this method request, and are its safety and idempotency properties defined by an applicable specification?", "kind": "definition", "id": "method-semantics-and-guarantees-q01" }, { "text": "What evidence supports the expected effects at this resource, including any request-content semantics or restrictions?", "kind": "provenance", "id": "method-semantics-and-guarantees-q02" } ] } ] } ] }, { "id": "responses-and-representations", "name": "Responses and representations", "description": "Records what a response means and how its content relates to a selected representation.", "rationale": "Status codes and content metadata jointly constrain interpretation; neither alone proves application success.", "layers": [ { "id": "status-and-response-sequence", "name": "Status and response sequence", "description": "Interprets informational and final responses in the context of the originating request.", "findings": [ { "id": "response-meaning", "name": "Response meaning", "description": "Record the response sequence and distinguish HTTP-level outcomes from application results requiring separate evidence.", "questions": [ { "text": "Which responses are informational, which is final, and what does the final status mean for this request method?", "kind": "definition", "id": "response-meaning-q01" }, { "text": "What remains unproven about the application outcome, particularly for accepted processing, absent content or an interrupted response?", "kind": "boundary", "id": "response-meaning-q02" } ] } ] }, { "id": "content-and-negotiation", "name": "Content and negotiation", "description": "Connects representation metadata and selection criteria to the content actually exchanged.", "findings": [ { "id": "selected-representation", "name": "Selected representation", "description": "Record declared representation properties, negotiation inputs and any mismatch between metadata and observed content.", "questions": [ { "text": "Which media type, content coding and language are declared, and what evidence confirms or contradicts those declarations?", "kind": "measurement", "id": "selected-representation-q01" }, { "text": "Which request preferences influenced representation selection, and is content expected or permitted for this method and status?", "kind": "boundary", "id": "selected-representation-q02" } ] } ] } ] }, { "id": "caching-and-conditional-transfer", "name": "Caching and conditional transfer", "description": "Records when an HTTP response can be reused and how validators or ranges constrain subsequent transfers.", "rationale": "HTTP permits avoiding or reducing transfers, but only when cache selection, freshness and precondition rules justify the action.", "layers": [ { "id": "stored-response-reuse", "name": "Stored response reuse", "description": "Evaluates storage and reuse in the context of a private or shared cache.", "findings": [ { "id": "cache-selection-and-freshness", "name": "Cache selection and freshness", "description": "Record cache context, matching criteria, directives, age and freshness evidence before reusing a response.", "questions": [ { "text": "May this cache store and reuse the response, considering its private or shared role, method, status and applicable directives?", "kind": "action", "id": "cache-selection-and-freshness-q01" }, { "text": "Do the target, method and Vary-selected request fields match, and what calculated age and freshness lifetime govern reuse?", "kind": "measurement", "id": "cache-selection-and-freshness-q02" } ] } ] }, { "id": "validators-preconditions-and-ranges", "name": "Validators, preconditions and ranges", "description": "Uses representation validators to condition operations and assess partial transfers.", "findings": [ { "id": "conditional-operation", "name": "Conditional operation", "description": "Record available entity tags or modification dates, their comparison requirements, and the intended role of preconditions or ranges.", "questions": [ { "text": "Which validators are available, and does the proposed precondition require a strong or weak comparison?", "kind": "definition", "id": "conditional-operation-q01" }, { "text": "Which conditional fields would validate a cached response or guard an update, and how should a 304 or 412 response change the next action?", "kind": "action", "id": "conditional-operation-q02" }, { "text": "If a range is requested, what supports range handling and representation continuity, and how will 206, 416 or a full response be handled?", "kind": "action", "id": "conditional-operation-q03" } ] } ] } ] }, { "id": "messaging-path-and-completion", "name": "Messaging path and completion", "description": "Records version-specific message boundaries, intermediary transformations and evidence of exchange completion.", "rationale": "Correct semantics depend on knowing what was actually transmitted and whether each hop interpreted the message consistently.", "layers": [ { "id": "version-framing-and-intermediaries", "name": "Version, framing and intermediaries", "description": "Relates shared HTTP semantics to the encoding and forwarding rules used on each observed hop.", "findings": [ { "id": "message-boundaries-and-forwarding", "name": "Message boundaries and forwarding", "description": "Record the HTTP version, framing evidence and known intermediary changes without assuming end-to-end wire equivalence.", "questions": [ { "text": "Which HTTP version is observed on each known hop, and what establishes the end of the message content and any trailers?", "kind": "measurement", "id": "message-boundaries-and-forwarding-q01" }, { "text": "Could conflicting length indicators, invalid fields or intermediary transformations cause different recipients to interpret different message boundaries?", "kind": "boundary", "id": "message-boundaries-and-forwarding-q02" } ] } ] }, { "id": "failure-and-retry", "name": "Failure and retry", "description": "Separates transport or stream failure from knowledge of whether the requested operation took effect.", "findings": [ { "id": "completion-evidence-and-repetition", "name": "Completion evidence and repetition", "description": "Record how far the exchange progressed and what evidence justifies repeating it.", "questions": [ { "text": "What evidence shows whether the request was transmitted, processed or answered completely, and where does the outcome remain unknown?", "kind": "measurement", "id": "completion-evidence-and-repetition-q01" }, { "text": "Do method semantics, a version-specific failure signal or a documented application guarantee justify a retry, and what timing guidance applies?", "kind": "action", "id": "completion-evidence-and-repetition-q02" } ] } ] } ] }, { "id": "credentials-and-follow-up-boundaries", "name": "Credentials and follow-up boundaries", "description": "Records HTTP authentication and routing signals that affect the authority and scope of subsequent requests.", "rationale": "An agent must interpret protocol prompts without assuming that they authorise credential disclosure or a new action.", "layers": [ { "id": "authentication-and-state-context", "name": "Authentication and state context", "description": "Distinguishes origin authentication, proxy authentication and application state carried in HTTP fields.", "findings": [ { "id": "credential-recipient-and-scope", "name": "Credential recipient and scope", "description": "Record challenges and credential or cookie scope through references that avoid retaining secret values unnecessarily.", "questions": [ { "text": "Does the response challenge origin authentication or proxy authentication, and which scheme and protection space does it identify?", "kind": "definition", "id": "credential-recipient-and-scope-q01" }, { "text": "Which credentials or cookies may accompany the next request, based on recipient scope, applicable client policy and the agent's existing authority?", "kind": "action", "id": "credential-recipient-and-scope-q02" } ] } ] }, { "id": "redirects-and-protocol-transitions", "name": "Redirects and protocol transitions", "description": "Evaluates changes to the request destination, method or communication mode.", "findings": [ { "id": "follow-up-request-boundary", "name": "Follow-up request boundary", "description": "Record what a redirect, successful CONNECT or protocol upgrade proposes and which semantics continue to apply.", "questions": [ { "text": "For a redirect, how is Location resolved, what method and content behaviour applies, and does the destination change origin or scheme?", "kind": "action", "id": "follow-up-request-boundary-q01" }, { "text": "If a tunnel or protocol upgrade is established, where does ordinary HTTP message interpretation stop and the neighbouring protocol model take over?", "kind": "boundary", "id": "follow-up-request-boundary-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "HTTP/0.9 (historical one-line GET with no headers)", "HTTP/1.0", "HTTP/1.1 (Host, persistent connections, chunked transfer)", "HTTP/2 (binary multiplexing and HPACK over TLS/TCP)", "HTTP/3 (HTTP semantics over QUIC/UDP)", "HTTP over TLS (HTTPS; same semantics, encrypted channel)", "Cleartext HTTP (http URI scheme, typically port 80)", "HTTP through intermediaries (origin, proxy, gateway, cache, CDN)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "scheme": "Wikidata", "value_or_pattern": "Q8777", "note": "Item for Hypertext Transfer Protocol" }, { "scheme": "IANA URI scheme", "value_or_pattern": "http | https", "note": "Registered schemes; https denotes HTTP over TLS" }, { "scheme": "TCP/UDP port", "value_or_pattern": "80 (http), 443 (https)", "note": "Default ports; HTTPS and HTTP/3 commonly use 443" }, { "scheme": "ALPN protocol ID", "value_or_pattern": "http/1.1 | h2 | h3", "note": "TLS Application-Layer Protocol Negotiation identifiers" }, { "scheme": "IANA HTTP Status Code Registry", "value_or_pattern": "NNN in 1xx-5xx", "note": "Assigned numeric status codes" }, { "scheme": "IANA HTTP Method Registry", "value_or_pattern": "token (e.g. GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS, CONNECT)", "note": "Registered method names" }, { "scheme": "Internet media type", "value_or_pattern": "message/http", "note": "Type for an HTTP message as a payload" } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "IETF RFC 9110 HTTP Semantics (Internet Engineering Task Force)", "IETF RFC 9111 HTTP Caching (Internet Engineering Task Force)", "IETF RFC 9112 HTTP/1.1 (Internet Engineering Task Force)", "IETF RFC 9113 HTTP/2 (Internet Engineering Task Force)", "IETF RFC 9114 HTTP/3 (Internet Engineering Task Force)", "IETF RFC 9204 QPACK: Field Compression for HTTP/3 (Internet Engineering Task Force)", "IETF RFC 2818 HTTP Over TLS (Internet Engineering Task Force)", "IETF RFC 8446 The Transport Layer Security Protocol Version 1.3, when HTTP runs over TLS (Internet Engineering Task Force)", "IETF RFC 3986 Uniform Resource Identifier (URI): Generic Syntax (Internet Engineering Task Force)", "IETF RFC 6265 HTTP State Management Mechanism (cookies) (Internet Engineering Task Force)", "IANA HTTP method, status-code, and field-name registries (Internet Assigned Numbers Authority, under IETF)", "WHATWG Fetch Standard (Web Hypertext Application Technology Working Group)", "EU GDPR and ePrivacy rules as they apply to cookies, identifiers, and tracking carried over HTTP (European Union)", "PCI DSS requirements to use TLS (HTTPS) when HTTP carries payment-card data (PCI Security Standards Council)" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Web browsers fetch HTML documents and subresources (scripts, styles, images, fonts) from origin servers.", "Native and web applications call JSON/REST, GraphQL, and similar APIs over HTTP.", "Reverse proxies, load balancers, and CDNs terminate or forward HTTP and apply caching, TLS, and routing.", "Services notify one another with HTTP webhooks and callbacks.", "Package registries, container registries, and software-update systems download artefacts over HTTP.", "Orchestrators and operators probe liveness and readiness with HTTP health-check endpoints.", "An HTTP Upgrade or CONNECT exchange is used to bootstrap WebSocket, tunnelling, or other protocols." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "quantity": "Protocol version", "typical_range": "0.9, 1.0, 1.1, 2, 3", "unit": "version identifier" }, { "quantity": "Status code", "typical_range": "100-599 (commonly 200, 301/302/304, 400/401/403/404, 500/502/503/504)", "unit": "code" }, { "quantity": "Time to first byte / round-trip latency", "typical_range": "about 1 ms on loopback; tens to a few hundred ms on typical Internet paths; seconds when congested or failing", "unit": "ms" }, { "quantity": "Request or response body size", "typical_range": "0 B to multi-GB downloads; typical HTML/API bodies from a few hundred bytes to a few MB", "unit": "byte" }, { "quantity": "Header block size", "typical_range": "a few hundred bytes to about 8-16 KiB before many servers reject the request", "unit": "byte" }, { "quantity": "HTTP/2 max concurrent streams", "typical_range": "often default 100; configurable from 1 to hundreds", "unit": "stream" }, { "quantity": "Redirect chain length", "typical_range": "0-5 in normal use; user agents commonly abort around 20 hops", "unit": "hop" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "HTTP request smuggling (Content-Length vs Transfer-Encoding desynchronisation) at HTTP/1.1 intermediaries", "Header injection and response splitting", "Web cache poisoning and inconsistent cache keys across CDNs and reverse proxies", "Cleartext HTTP exposing credentials, cookies, and bodies to interception (TLS stripping, mixed content)", "Connection-exhaustion denial of service (e.g. Slowloris) and HTTP/2 Rapid Reset style stream attacks", "Compression side-channels on HTTPS bodies (BREACH)", "Redirect loops and open redirects", "Origin or gateway 5xx failures, timeouts, and broken persistent connections", "Cookie theft and session fixation, especially without Secure/HttpOnly and without HTTPS", "QUIC/UDP blocking that breaks or delays HTTP/3 with fallback to HTTP/2 or HTTP/1.1" ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Some networks and national filters block or degrade UDP/443, so HTTP/3 is unavailable while HTTP/1.1 and HTTP/2 still work.", "State inspection and blocking is far more effective against cleartext HTTP than against HTTPS.", "Cookie consent, tracking, and retention rules differ (EU GDPR/ePrivacy versus other jurisdictions).", "Browser HTTPS-only mode, HSTS preload, and certificate-authority trust stores are not uniform worldwide.", "Accept-Language and default character encoding historically varied by locale and vendor, affecting content negotiation." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "name": "HTTPS", "difference": "HTTPS is HTTP over TLS (https URI, typically port 443 and a TLS handshake). HTTP semantics are the same; confidentiality and server authentication come from TLS, not from a different application protocol." }, { "name": "QUIC", "difference": "QUIC is the transport. HTTP/3 is HTTP semantics mapped onto QUIC streams (ALPN h3). Other ALPN protocols can run on QUIC without being HTTP." }, { "name": "WebSocket", "difference": "WebSocket is a separate framed protocol. It may start with an HTTP Upgrade; after 101 Switching Protocols, subsequent frames are not HTTP messages." }, { "name": "REST", "difference": "REST is an architectural style that often uses HTTP. HTTP can carry non-REST payloads (RPC, file transfer, SOAP); REST constraints can be applied on other transfers." }, { "name": "HTML", "difference": "HTML is a document format commonly carried as an HTTP representation (Content-Type text/html). The protocol is the request line, status line, and fields, not the markup." }, { "name": "gRPC", "difference": "gRPC is an RPC system typically multiplexed on HTTP/2 or HTTP/3 with content-type application/grpc and protobuf messages, not ordinary resource representations." }, { "name": "SPDY", "difference": "SPDY was Google's obsolete predecessor to HTTP/2. Distinguish by ALPN/NPN tokens spdy/* versus h2." }, { "name": "CoAP", "difference": "CoAP is a constrained request/response protocol over UDP (commonly port 5683) with its own binary header; it is analogous in role, not a version of HTTP." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of HTTP this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "With no registry definition recorded, should this entry cover only the HTTP protocol family or also provide reusable records for individual exchanges and endpoint capabilities?", "Which specification baseline and extension set should be adopted, including treatment of legacy HTTP/1.0, registered extension methods and evolving field definitions?", "Where should the catalogue place cookie handling and browser-enforced policies so that this model can reference their effects without duplicating ownership?", "What evidence will normally be available across intermediaries, and how should the model express conclusions that are valid only for one observed hop?", "Which neighbouring model owns application-level idempotency keys and asynchronous operation completion, and what evidence must HTTP retry decisions obtain from it?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 29 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "discipline or field of knowledge", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a HTTP, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise HTTP interactions, assess their semantic and operational state, and determine which requests, retries, reuse and forwarding actions are justified.", "characteristics": { "substance": "information", "origin": "conceptual", "agency": "inert" }, "whatYouCanDoWithIt": [ "read and interpreted" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: Secure Hypertext Transfer Protocol, HTTPS.", "2 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 97 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a HTTP, and on what evidence are they told apart?" ], "whatItIsMadeOf": "content that has to be carried by something else", "physicalCharacter": [ "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "read it and act on what it says" ], "howItIsRecognised": [], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "Secure Hypertext Transfer Protocol", "HTTPS" ] } ], "standing": "Described in 97 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 2 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one HTTP from another, and a HTTP from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a HTTP sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a HTTP from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a HTTP passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a HTTP between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a HTTP, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a HTTP is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "content-and-access", "name": "Content, encoding and access", "description": "What a HTTP says, how it is encoded and who may read it.", "rationale": "An informational thing carries content that can be copied, versioned and withheld, none of which its physical carrier explains.", "layers": [ { "id": "content-and-encoding", "name": "Content and encoding", "description": "The content itself, its format and its language.", "findings": [ { "id": "content-and-format", "name": "Content, format and language", "description": "What a HTTP contains and in what form it is held.", "questions": [ { "id": "content-and-format-q01", "text": "What identifies and describes the content of a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "content-and-format-q02", "text": "Who or what asserted this about the content of a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "content-and-format-q03", "text": "What may an agent decide or do once the content of a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "access-and-rights", "name": "Access, rights and retention", "description": "Who may read, copy or change it, and for how long it is kept.", "findings": [ { "id": "access-rules", "name": "Access rules and retention", "description": "The permissions attached to a HTTP and the period it survives.", "questions": [ { "id": "access-rules-q01", "text": "What identifies and describes access to a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "access-rules-q02", "text": "Who or what asserted this about access to a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "access-rules-q03", "text": "What may an agent decide or do once access to a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "subject-and-method", "name": "Subject matter and method", "description": "What HTTP studies and how it establishes anything.", "rationale": "A field is identified by its questions and its methods, and those are what distinguish it from the fields next to it.", "layers": [ { "id": "subject", "name": "Subject matter", "description": "The questions it takes as its own.", "findings": [ { "id": "subject-record", "name": "Questions and objects of study", "description": "What it is about, stated so a neighbouring field can be told apart.", "questions": [ { "id": "subject-record-q01", "text": "What questions and objects does HTTP take as its own?", "kind": "definition" }, { "id": "subject-record-q02", "text": "Which questions does it share with a neighbouring field, and who claims them?", "kind": "boundary" } ] } ] }, { "id": "method", "name": "Method and evidence", "description": "How claims are established and what counts as evidence.", "findings": [ { "id": "method-record", "name": "Methods and standards of evidence", "description": "The methods used and what they are taken to establish.", "questions": [ { "id": "method-record-q01", "text": "By what methods does HTTP establish claims, and what counts as sufficient evidence?", "kind": "provenance" }, { "id": "method-record-q02", "text": "What kind of claim can this field not settle, and where should an agent look instead?", "kind": "action" } ] } ] } ] }, { "id": "institutions-and-classification", "name": "Institutions and classification", "description": "Where HTTP is practised and how catalogues place it.", "rationale": "The institutional footprint is the evidence that a field exists as a field rather than as a topic.", "layers": [ { "id": "institutions", "name": "Institutional markers", "description": "Societies, journals, degrees and departments.", "findings": [ { "id": "institution-record", "name": "Bodies and venues", "description": "Where the field organises itself.", "questions": [ { "id": "institution-record-q01", "text": "Which societies, journals or degrees mark HTTP as an established field?", "kind": "provenance" }, { "id": "institution-record-q02", "text": "What would show that it is emerging or dissolving rather than established?", "kind": "boundary" } ] } ] }, { "id": "classification", "name": "Classification schemes", "description": "Where library and research classifications put it.", "findings": [ { "id": "classification-record", "name": "Codes and their disagreements", "description": "The classification codes that place it, and where they differ.", "questions": [ { "id": "classification-record-q01", "text": "Which classification schemes place HTTP, under what codes?", "kind": "definition" }, { "id": "classification-record-q02", "text": "Where do those schemes disagree about its scope?", "kind": "boundary" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a HTTP came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a HTTP and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a HTTP is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a HTTP, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a HTTP, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a HTTP is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 12, "findings": 14, "questions": 38 } } } }