Internet-Draft Web4 Terminology August 2026
Jacobs Expires 9 February 2027 [Page]
Workgroup:
Individual Submission
Internet-Draft:
draft-jacobs-web4-terminology-00
Published:
Intended Status:
Informational
Expires:
Author:
T. Jacobs
KTS Global

Web4 Terminology and Definitions

Abstract

This document defines a common vocabulary for describing Web4 systems: federated, sovereign-entity-capable network architectures that extend prior generations of the Web with machine-native comprehension and conformance evaluation. It establishes baseline terminology intended for reference by subsequent Web4 specifications, including but not limited to [JACOBS-MEC], and is written to be independently useful to any implementer or evaluator working with Web4-class systems, regardless of underlying implementation.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 9 February 2027.

Table of Contents

1. Introduction

Successive generations of Web architecture are commonly referenced using informal generational labels ("Web1", "Web2", "Web3") without settled, citable definitions. This creates ambiguity when specifications, implementers, or evaluators attempt to describe systems that exhibit federation, autonomous machine participation, or sovereign data control -- properties increasingly associated with the informal term "Web4."

This document does not specify a protocol, an architecture, or an implementation. It defines terminology only, so that this and future documents can refer to a shared, stable vocabulary rather than re-deriving definitions in each specification. Bounding the scope in this way keeps the terminology reusable across independent implementations and avoids tying the vocabulary to any single vendor's internal design.

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

3. Core Definitions

3.1. Web4

Web4 refers to a class of network architectures in which participating nodes are independently operable, cryptographically or procedurally identifiable, capable of federated interconnection without a single controlling authority, and capable of exposing behavior that can be evaluated for machine comprehension (Section 3.5). Web4 is a descriptive category, not a single protocol; a system MAY be described as Web4-class if it satisfies these properties, regardless of its internal implementation.

3.2. Sovereign Entity

A sovereign entity is a participant in a Web4 system -- human, organizational, or machine -- that retains independent control over its own data, identity, and participation decisions, and whose behavior within the federation is externally observable and evaluable without requiring disclosure of internal implementation details.

3.3. Federation Node

A federation node is an addressable, independently operable endpoint that participates in a Web4 federation. A node MAY join or leave a federation, and its participation status is determined by an allowlist, protocol handshake, or equivalent admission mechanism defined by the federation's operator(s).

3.4. Tiering

Tiering describes the practice of organizing federation nodes into layered relationships (e.g., coordinating nodes and subordinate nodes) for purposes of routing, visibility, or policy enforcement. Tiering is an organizational property of a federation and does not imply any specific transport, storage, or computational mechanism.

3.5. Machine Comprehension

Machine comprehension, in the Web4 context, refers to a system's demonstrated ability to process, relate, and respond to novel inputs in a manner that is externally distinguishable from simple retrieval or lookup, as established through defined test procedures and reference outcomes. This document takes no position on the internal mechanism by which comprehension is achieved.

3.6. Conformance Class

A conformance class is a named set of criteria against which a Web4 node or federation may be evaluated. Conformance classes are composite in nature and MAY combine criteria drawn from comprehension testing, federation behavior, security posture, and operational transparency. A conformance class does not certify fitness for any particular purpose; it certifies that stated criteria were met under stated test conditions.

3.7. Reference Implementation

A reference implementation is a deployed, operational Web4 system used to demonstrate that a given definition or conformance class is achievable in practice rather than purely theoretical. Citation of a reference implementation in a Web4 specification does not grant that implementation any normative status over the specification itself.

3.8. Adjudication Record

An adjudication record is a preserved, time-stamped account of a specific conformance evaluation, including the test conditions, the reference outcome expected, and the outcome observed. Adjudication records are intended to support independent verification and SHOULD be retained by the evaluating party.

4. Relationship to Prior Web Generations

This document does not attempt to formally define "Web1", "Web2", or "Web3", as no single citable definition for those terms has achieved broad consensus. Where comparison is useful, this document treats Web4 as distinguished primarily by (a) federated, multi-operator participation without a single controlling authority, and (b) the presence of testable machine comprehension properties, rather than by any specific transport or storage technology.

5. Security Considerations

This document defines terminology only and introduces no protocol, wire format, or executable behavior. It therefore introduces no new security vulnerabilities directly. Future Web4 specifications that rely on these definitions SHOULD include their own Security Considerations addressing node admission, federation trust boundaries, and comprehension-test integrity, as terminology choices alone do not constrain implementation security properties.

6. IANA Considerations

This document has no IANA actions.

7. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, , <https://www.rfc-editor.org/info/rfc8174>.

8. Informative References

[JACOBS-MEC]
Jacobs, T., "Web4 Sovereign Entity Comprehension: Requirements and External Conformance Framework", , <https://datatracker.ietf.org/doc/draft-jacobs-web4-sovereign-entity-comprehension/>.

Author's Address

Tim Jacobs
KTS Global
United Arab Emirates