\/<\/p>Specification<\/a>\/<\/p>Wire bindings<\/b> One binding per plane, each an open standard.<\/h1> The normative wire bindings of Observatory Protocol 0.1: control, data, events, exchange, evidence and telemetry.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Lineage<\/span><\/li>Wire bindings<\/span><\/li>References<\/span><\/li><\/ol><\/nav>The practice this part continues.<\/h2> <\/header>1984 End to end, rough consensus<\/dt>Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet\u2019s architecture. The IETF\u2019s working method, summarised in RFC 7282 as \u201crough consensus and running code\u201d, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [1]<\/span><\/sup>[2]<\/span><\/sup>[3]<\/span><\/sup><\/dd> <\/dl><\/section>Normative bindings for Observatory Protocol 0.1.<\/h2>The control, data, evidence and exchange planes are separate; the exchange plane never opens an inbound management path into a site.<\/p> <\/header>Control<\/dt>TLS 1.3 with mutual authentication; protobuf messages over gRPC or HTTP\/2.<\/dd> Data, in the field<\/dt>MQTT 5 with Sparkplug B; connectors for LoRaWAN, OPC UA and instrument buses.<\/dd> Data, site to upstream<\/dt>At-least-once publication with repeat-safe keys over the control channel or NATS JetStream; QUIC MAY be used on lossy links.<\/dd> Events<\/dt>Event envelopes mapped to CloudEvents 1.0; channels described in AsyncAPI 3.<\/dd> Exchange<\/dt>OpenAPI 3.1; the OGC API family; SensorThings; STAC; WIS 2.0.<\/dd> Evidence<\/dt>DSSE-signed in-toto statements; SLSA provenance; SCITT transparency receipts.<\/dd> Telemetry<\/dt>OpenTelemetry OTLP.<\/dd> <\/dl><\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu\/Saltzer\/www\/publications\/endtoend\/endtoend.pdf<\/a><\/li>Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org\/rfc\/rfc1958<\/a><\/li>Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org\/rfc\/rfc7282<\/a><\/li>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
\/<\/p>Wire bindings<\/b> One binding per plane, each an open standard.<\/h1>
The normative wire bindings of Observatory Protocol 0.1: control, data, events, exchange, evidence and telemetry.<\/p> Read the specification<\/a>Contribute<\/a> Functions<\/dt>12<\/dd> State machines<\/dt>11<\/dd> Objects<\/dt>21<\/dd> Standards<\/dt>48<\/dd> <\/dl> <\/section> Specification<\/a>Functions<\/a>State machines<\/a>Flows<\/a>Objects<\/a>Participants<\/a>Standards<\/a>Conformance<\/a>Governance<\/a>Changes<\/a>Implementers<\/a>Wire bindings<\/a>Reference scenes<\/a> <\/nav> On this page<\/p>Lineage<\/span><\/li>Wire bindings<\/span><\/li>References<\/span><\/li><\/ol><\/nav>The practice this part continues.<\/h2> <\/header>1984 End to end, rough consensus<\/dt>Saltzer, Reed and Clark argued that functions placed in the network can be completely and correctly implemented only with the knowledge of the end systems; RFC 1958 recorded the principle for the Internet\u2019s architecture. The IETF\u2019s working method, summarised in RFC 7282 as \u201crough consensus and running code\u201d, sets the standard for how an open protocol should change. The protocol keeps authority at the site and changes only through open proposals. [1]<\/span><\/sup>[2]<\/span><\/sup>[3]<\/span><\/sup><\/dd> <\/dl><\/section>Normative bindings for Observatory Protocol 0.1.<\/h2>The control, data, evidence and exchange planes are separate; the exchange plane never opens an inbound management path into a site.<\/p> <\/header>Control<\/dt>TLS 1.3 with mutual authentication; protobuf messages over gRPC or HTTP\/2.<\/dd> Data, in the field<\/dt>MQTT 5 with Sparkplug B; connectors for LoRaWAN, OPC UA and instrument buses.<\/dd> Data, site to upstream<\/dt>At-least-once publication with repeat-safe keys over the control channel or NATS JetStream; QUIC MAY be used on lossy links.<\/dd> Events<\/dt>Event envelopes mapped to CloudEvents 1.0; channels described in AsyncAPI 3.<\/dd> Exchange<\/dt>OpenAPI 3.1; the OGC API family; SensorThings; STAC; WIS 2.0.<\/dd> Evidence<\/dt>DSSE-signed in-toto statements; SLSA provenance; SCITT transparency receipts.<\/dd> Telemetry<\/dt>OpenTelemetry OTLP.<\/dd> <\/dl><\/section>References<\/h2>Sources for the historical and standards statements on this page.<\/p> <\/header>Saltzer, J. H., Reed, D. P., and Clark, D. D. (1984). “End-to-End Arguments in System Design.” ACM Transactions on Computer Systems 2(4). web.mit.edu\/Saltzer\/www\/publications\/endtoend\/endtoend.pdf<\/a><\/li>Carpenter, B., ed. (1996). RFC 1958, “Architectural Principles of the Internet.” IETF. www.rfc-editor.org\/rfc\/rfc1958<\/a><\/li>Resnick, P. (2014). RFC 7282, “On Consensus and Humming in the IETF.” IETF. www.rfc-editor.org\/rfc\/rfc7282<\/a><\/li>Bradner, S. (1997). RFC 2119, “Key words for use in RFCs to Indicate Requirement Levels.” IETF. www.rfc-editor.org\/rfc\/rfc2119<\/a><\/li>Leiba, B. (2017). RFC 8174, “Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words.” IETF. www.rfc-editor.org\/rfc\/rfc8174<\/a><\/li><\/ol><\/section><\/main> Read it, test it, propose a change.<\/h2>The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>
On this page<\/p>
The control, data, evidence and exchange planes are separate; the exchange plane never opens an inbound management path into a site.<\/p> <\/header>
Sources for the historical and standards statements on this page.<\/p> <\/header>
The Observatory Protocol is an open specification stewarded by the Nexus Consortium. Any party may implement it, and every change is proposed and decided in public.<\/p> Read the specification<\/a>Contribute<\/a> <\/section>