Towards SemBr

standards/application/contentframe.md

@@ -9,35 +9,41 @@ contributors:
 
 ## Abstract
 
-This specification defines ContentFrame, a self-describing message format for decentralized chat networks. ContentFrame wraps content payloads with metadata identifying their type and governing specification repository. Using a `(domain, tag)` tuple, applications can uniquely identify message types and locate authoritative documentation for parsing unfamiliar content. This approach enables permissionless innovation while maintaining the context needed for interoperability, allowing applications to gracefully handle messages from sources they don't explicitly know about.
+This specification defines ContentFrame, a self-describing message format for decentralized chat networks.
+ContentFrame wraps content payloads with metadata identifying their type and governing specification repository.
+Using a `(domain, tag)` tuple, applications can uniquely identify message types and locate authoritative documentation for parsing unfamiliar content.
+This approach enables permissionless innovation while maintaining the context needed for interoperability, allowing applications to gracefully handle messages from sources they don't explicitly know about.
 
 ## Motivation
 
-In an interoperable chat network, participants cannot be assumed to use the same software to send and receive messages. Users may employ different versions of the same application or different applications entirely. This heterogeneity creates a fundamental challenge: how can applications support extensible message types without prior knowledge of every possible format?
+In an interoperable chat network, participants cannot be assumed to use the same software to send and receive messages.
+Users may employ different versions of the same application or different applications entirely.
+This heterogeneity creates a fundamental challenge: how can applications support extensible message types without prior knowledge of every possible format?
 
 Two naive approaches each have significant drawbacks:
 
-**Developer-defined types** would allow flexibility but create fragmentation. When developers define their own message types, the context for parsing these messages remains tightly coupled to the software that created them. Other applications receiving these messages lack the necessary context to interpret them correctly. This leads to multiple definitions of basic types such as `Text` and `Image` that are not compatible across applications.
+**Developer-defined types** would allow flexibility but create fragmentation.
+When developers define their own message types, the context for parsing these messages remains tightly coupled to the software that created them.
+Other applications receiving these messages lack the necessary context to interpret them correctly.
+This leads to multiple definitions of basic types such as `Text` and `Image` that are not compatible across applications.
 
-**Fixed type systems** would ensure universal understanding but restrict innovation. A predetermined set of message types eliminates ambiguity but adds friction for developers who want to extend functionality. In a permissionless, decentralized protocol, requiring centralized approval for new message types contradicts core design principles.
+**Fixed type systems** would ensure universal understanding but restrict innovation.
+A predetermined set of message types eliminates ambiguity but adds friction for developers who want to extend functionality.
+In a permissionless, decentralized protocol, requiring centralized approval for new message types contradicts core design principles.
 
 The core challenge is managing fragmentation in a decentralized protocol while preserving developer freedom to innovate.
 
-**Solution:** A self-describing message format that encodes both the payload and the metadata needed to parse it. This approach directs application developers on how a message should be parsed while providing a clear path to learn about unfamiliar content types they encounter. By decoupling the encoded data from the specific software that created it, applications can gracefully handle messages from diverse sources without sacrificing extensibility.
+**Solution:** A self-describing message format that encodes both the payload and the metadata needed to parse it.
+This approach directs application developers on how a message should be parsed while providing a clear path to learn about unfamiliar content types they encounter.
+By decoupling the encoded data from the specific software that created it, applications can gracefully handle messages from diverse sources without sacrificing extensibility.
 
 
 ## Theory / Semantics
 
-### Definitions
-
-This document makes use of the shared terminology defined in the [CHATDEFS]() protocol.
-
-[Payload, Application, client]
-
-
 ### ContentFrame
 
-A ContentFrame provides a self-describing format for payload types by encoding both the type identifier and its administrative origin. The core principle is that each payload should declare which entity is responsible for its definition and provide a unique type discriminator within that entity's namespace.
+A ContentFrame provides a self-describing format for payload types by encoding both the type identifier and its administrative origin.
+The core principle is that each payload should declare which entity is responsible for its definition and provide a unique type discriminator within that entity's namespace.
 
 A ContentFrame consists of two key components:
 
@@ -73,7 +79,8 @@ flowchart TD
 
 ### Domain
 
-A domain identifies the authority responsible for defining and governing a set of content types. By including the domain, receiving applications can locate the authoritative specification for a type, regardless of which application originally sent it.
+A domain identifies the authority responsible for defining and governing a set of content types.
+By including the domain, receiving applications can locate the authoritative specification for a type, regardless of which application originally sent it.
 
 **Requirements:**
 
@@ -83,12 +90,14 @@ A domain identifies the authority responsible for defining and governing a set o
 
 **Specification Format:**
 
-Domains are responsible for describing their types in whatever format is most appropriate. The only requirement is that the information needed to parse and understand each type is accessible from the domain URL.
+Domains are responsible for describing their types in whatever format is most appropriate.
+The only requirement is that the information needed to parse and understand each type is accessible from the domain URL.
 
 
 **Domain ID Mapping:**
 
-To minimize payload size, domains are mapped to integer identifiers. Each domain is assigned a unique `domain_id` which is used in the wire format instead of the full URL.
+To minimize payload size, domains are mapped to integer identifiers.
+Each domain is assigned a unique `domain_id` which is used in the wire format instead of the full URL.
 
 - A `domain_id` MUST be a positive integer value
 - A `domain_id` MUST correspond to exactly one unique domain
@@ -96,7 +105,8 @@ To minimize payload size, domains are mapped to integer identifiers. Each domain
 
 ### Tag
 
-A tag is a numeric identifier that uniquely specifies a content type within a domain's namespace. After resolving the domain and tag, application developers have all the information needed to locate the definition and parse the payload.
+A tag is a numeric identifier that uniquely specifies a content type within a domain's namespace.
+After resolving the domain and tag, application developers have all the information needed to locate the definition and parse the payload.
 
 **Requirements:**
 
@@ -138,11 +148,14 @@ All fields are required.
 
 ### Tags to Specifications
 
-Where possible, tag values should directly correspond to specification identifiers. Using specification IDs as tags removes the need to maintain a separate mapping between tags and specifications.
+Where possible, tag values should directly correspond to specification identifiers.
+Using specification IDs as tags removes the need to maintain a separate mapping between tags and specifications.
 
 ### Fragmentation
 
-This protocol allows multiple competing definitions of similar content types. Having multiple definitions of `Text` or `Image` increases fragmentation between applications. Where possible, reusing existing types will reduce burden on developers and increase interoperability.
+This protocol allows multiple competing definitions of similar content types.
+Having multiple definitions of `Text` or `Image` increases fragmentation between applications.
+Where possible, reusing existing types will reduce burden on developers and increase interoperability.
 
 Domains should focus on providing types unique to their service or use case.
 
@@ -151,7 +164,8 @@ Domains should focus on providing types unique to their service or use case.
 
 ![TODO] Find appropriate home for this registry.
 
-Domain IDs are assigned sequentially on a first-come, first-served basis. New domains are added via pull request.
+Domain IDs are assigned sequentially on a first-come, first-served basis.
+New domains are added via pull request.
 
 **Registry Rules:**