RFC 9880's Semantic Definition Format Could End IoT's Data Model Chaos

The Internet of Things has a fundamental problem that better protocols can't solve: devices speak different data languages. RFC 9880's Semantic Definition Format (SDF) represents the IETF's ambitious attempt to create a universal translator for IoT device models.

While most IoT discussions focus on connectivity protocols and security, the real fragmentation happens at the data model layer. Every vendor, platform, and standard body has created their own way to describe what devices do and what data they produce. The result? A Tower of Babel where smart thermostats, industrial sensors, and medical devices all speak incompatible dialects.

The Real Problem SDF Solves

Consider a simple temperature sensor. In one system, it might expose readings as {"temp": 23.5, "unit": "celsius"}. Another platform expects {"temperature_c": 23.5, "timestamp": 1640995200}. A third requires {"value": 235, "scale": -1, "units": "degC"}. Same data, three incompatible models.

SDF addresses this by providing a standardized JSON Schema-based format for describing device capabilities. But here's what makes it interesting for developers: SDF is stricter than generic JSON Schema, catching validation errors that would slip through traditional approaches.

1{
2  "sdfThing": {
3    "TemperatureSensor": {
4      "sdfProperty": {
5        "temperature": {
6          "type": "number",
7          "unit": "Cel",
8          "readable": true,

This SDF definition tells any system exactly what to expect: a readable and observable temperature property with specific bounds and units. The readable flag indicates you can poll for current values, while observable means the device can push notifications when values change—a critical distinction for battery-powered devices.

Beyond JSON Schema: Stricter Validation

SDF's key innovation isn't just standardization—it's enhanced validation. Where JSON Schema might accept an integer like 23 for a property that should be a multiple of 2, SDF's stricter enforcement would catch this mismatch early. For IoT deployments managing critical infrastructure, this extra validation layer prevents configuration errors that could propagate across hundreds or thousands of devices.

1// This would pass basic JSON Schema validation
2const invalidReading = { temperature: 23, multiplier: 3 }; // multiplier should be multiple of 2
3
4// But SDF validation would reject it
5const sdfValidator = new SDFValidator(deviceModel);
6if (!sdfValidator.validate(invalidReading)) {
7  throw new Error('Data violates device model constraints');
8}

The Device-Model Compiler Vision

The most intriguing concept emerging from SDF adoption is the idea of a "device-model compiler"—tools that could generate platform-specific integration code from SDF definitions. Instead of manually writing device drivers for each platform, developers could define their device once in SDF and generate adapters for AWS IoT, Azure IoT Hub, Google Cloud IoT, or industrial control systems.

Imagine this workflow:

1sdf-compile --input sensor.sdf --target aws-iot --output ./aws-adapter/
2sdf-compile --input sensor.sdf --target azure-iot --output ./azure-adapter/
3sdf-compile --input sensor.sdf --target opcua --output ./opcua-adapter/

This isn't theoretical—the standardization of device models through SDF makes such compilation feasible.

Security Through Model Validation

SDF also addresses a critical security concern: how do constrained IoT devices validate that software updates are appropriate for their hardware? By embedding SDF models in devices, systems can verify that incoming updates match expected data structures and interaction patterns before installation.

1interface UpdateValidator {
2  validateUpdate(update: FirmwareUpdate, deviceModel: SDFModel): boolean;
3}
4
5class SecureUpdateManager implements UpdateValidator {
6  validateUpdate(update: FirmwareUpdate, deviceModel: SDFModel): boolean {
7    // Verify update matches device capabilities
8    if (!this.modelMatches(update.requiredModel, deviceModel)) {
9      return false;
10    }
11    
12    // Validate data structure compatibility
13    return this.validateDataStructures(update.dataSchema, deviceModel.sdfProperty);
14  }
15}

This model-based validation prevents installation of mismatched firmware—a common attack vector in IoT systems.

Integration Challenges and Opportunities

SDF works alongside existing IoT protocols like CoAP and security standards like OSCORE, but adoption requires tooling ecosystem development. The specification is solid, but we need:

• SDF editors for creating and validating device models
• Code generators for popular IoT platforms
• Runtime validators for embedded systems
• Translation tools for converting existing proprietary models to SDF

Why This Matters

RFC 9880 represents more than just another IoT standard—it's an attempt to solve the fundamental interoperability problem that has plagued IoT since its inception. For developers building IoT platforms, device management systems, or integration tools, SDF offers a path toward true device interoperability.

The immediate opportunity lies in adopting SDF for new device descriptions and building the tooling ecosystem around it. Early adopters who create robust SDF-based device models and compilation tools will have significant advantages as the standard gains traction.

Start by examining your current device description formats. Could they be expressed in SDF? What would a device-model compiler look like for your platform? The IoT industry's fragmentation problem finally has a standardized solution—the question is whether we'll use it.