SDF Protocol Mapping

Internet-Draft	sdf-protocol-mapping	August 2026
Mohan, et al.	Expires 28 February 2027	[Page]

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 28 February 2027.¶

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

1. Introduction

The Semantic Definition Format (SDF) [RFC9880] provides a protocol-agnostic way to describe IoT devices and their capabilities through properties, actions, and events (collectively called affordances). A device described by an SDF model, however, is accessed over a specific communication protocol. To interact with such a device based on its SDF model, there needs to be a mechanism to map the protocol-agnostic SDF definitions to the protocol-specific operations that access the device. Moreover, such a mechanism needs to be extensible for enabling implementers to provide novel SDF protocol mappings to expand the SDF ecosystem. SDF protocol mappings may target a variety of protocols spanning from non-IP protocols commonly used in IoT environments, such as [BLE53] and [Zigbee30], to IP-based protocols such as HTTP [RFC9110] and CoAP [RFC7252]. This document provides the required mechanism by defining:¶

The sdfProtocolMap quality, which allows SDF models to include protocol-specific mapping information attached to the protocol-agnostic definitions, see Section 3. An sdfProtocolMap MAY be applied to an SDF affordance, be it an sdfProperty, sdfEvent or sdfAction. The mapping enables use cases such as application gateways or multi-protocol gateways that translate between different IoT protocols, automated generation of protocol-specific implementations from SDF models, and interoperability across heterogeneous device ecosystems.¶
Two SDF protocol mappings for Bluetooth and Zigbee protocols, see Section 4.1 and Section 4.2 respectively.¶
An SDF model extension for SCIM. While SDF provides a way to describe a class of devices, SCIM describes a device instance. The SDF model extension for SCIM enables the inclusion of SDF models for the class of devices a device belongs to in the SCIM object, see Section 5.¶
An IANA registry for defining additional SDF protocol mappings (in addition to the BLE and Zigbee provided in this document), see Section 8.1.¶

2. Conventions and Definitions

The syntax extensions to [RFC9880] are shown in the Concise Data Definition Language (CDDL) [RFC8610], which describes their JSON representation.¶

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. SDF Protocol Mapping Structure

This section defines the structure of an sdfProtocolMap. Because each protocol has its own addressing model, a single SDF affordance requires a distinct mapping per protocol. For example, BLE addresses a property as a service characteristic, while Zigbee addresses it as an attribute in a cluster of an endpoint.¶

The value of the sdfProtocolMap quality is a JSON object nested inside an SDF affordance definition (sdfProperty, sdfAction, or sdfEvent). Protocol-specific attributes are embedded within this object, keyed by a protocol name registered in the IANA "SDF Protocol Mapping" registry (Section 8.1), e.g., "ble" or "zigbee".¶

Figure 1: SDF Protocol Mapping Structure

3.1. SDF Extension Points

The sdfProtocolMap quality is introduced into SDF affordance definitions through the extension points defined in the formal syntax of Appendix A of [RFC9880]. For each affordance type, an sdfProtocolMap entry is added via the corresponding CDDL group socket. The contents of the sdfProtocolMap object are in turn extensible through a protocol-mapping-specific group socket.¶

A protocol MAY choose to extend only the affordance types that are applicable to it. For example, the BLE protocol mapping defines extensions for properties and events but not for actions.¶

3.1.1. Property Extension

The $$SDF-EXTENSION-PROPERTY group socket in the propertyqualities rule of Appendix A of [RFC9880] is used to add protocol mapping to sdfProperty definitions:¶

$$SDF-EXTENSION-PROPERTY //= (
  sdfProtocolMap: {
    * $$SDF-PROPERTY-PROTOCOL-MAP
  }
)

property-protocol-map<name, props, read-props, write-props> = (
  name => props /
    {
      read: read-props,
      write: write-props
    }
)

Figure 2: SDF Property Extension Point for Protocol Mapping

The property-protocol-map generic (Figure 2) captures the common structure of property protocol mappings. The name parameter is the protocol name and props is the protocol-specific map of attributes. A protocol can provide either:¶

A single mapping that applies to both read and write operations, or¶
Separate read and write mappings when the protocol uses different attributes for each direction.¶

To keep these two forms unambiguous, the protocol-specific attribute map (the props type) MUST NOT define members named read or write.¶

To extend $$SDF-PROPERTY-PROTOCOL-MAP for a new protocol (e.g., "new-protocol"), implementers MUST use the property-protocol-map generic with the protocol name and a map type defining the protocol-specific attributes.¶

It is to be noted that the protocol name (e.g., "new-protocol") MUST be registered in the IANA registry defined in Section 8.1.¶

For a fictitious "new-protocol" that uses the same attributes for both read and write operations, the generic invocation could be defined as:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"new-protocol", new-protocol-property, new-\
                            protocol-property, new-protocol-property>
)

new-protocol-property = {
  attributeA: text,
  attributeB: uint
}

Figure 3: Example Property Protocol Map Extension

An SDF model using a single mapping for both read and write operations could look like:¶

{
  "sdfProperty": {
    "temperature": {
      "type": "number",
      "unit": "Cel",
      "sdfProtocolMap": {
        "new-protocol": {
          "attributeA": "temperature-service",
          "attributeB": 1
        }
      }
    }
  }
}

Figure 4: Example Property Protocol Map with a Single Mapping

An SDF model using separate read and write mappings could look like:¶

{
  "sdfProperty": {
    "temperature": {
      "type": "number",
      "unit": "Cel",
      "sdfProtocolMap": {
        "new-protocol": {
          "read": {
            "attributeA": "temperature-read-service",
            "attributeB": 1
          },
          "write": {
            "attributeA": "temperature-write-service",
            "attributeB": 2
          }
        }
      }
    }
  }
}

Figure 5: Example Property Protocol Map with Separate Read and Write Mappings

When a protocol instead uses different attributes for read and write operations, the read-props and write-props type parameters can be given distinct types:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"new-protocol", new-protocol-property, new-\
                 protocol-property-read, new-protocol-property-write>
)

new-protocol-property-read = {
  attributeA: text
}

new-protocol-property-write = {
  attributeA: text,
  attributeB: uint
}

Figure 6: Example Property Protocol Map Extension with Distinct Read and Write Attribute Types

An SDF model using this extension could look like:¶

{
  "sdfProperty": {
    "temperature": {
      "type": "number",
      "unit": "Cel",
      "sdfProtocolMap": {
        "new-protocol": {
          "read": {
            "attributeA": "temperature-read-service"
          },
          "write": {
            "attributeA": "temperature-write-service",
            "attributeB": 2
          }
        }
      }
    }
  }
}

Figure 7: Example Property Protocol Map with Distinct Read and Write Attributes

3.1.2. Action Extension

The $$SDF-EXTENSION-ACTION group socket in the actionqualities rule of Appendix A of [RFC9880] is used to add protocol mapping to sdfAction definitions:¶

$$SDF-EXTENSION-ACTION //= (
  sdfProtocolMap: {
    * $$SDF-ACTION-PROTOCOL-MAP
  }
)

Figure 8: SDF Action Extension Point for Protocol Mapping

Actions use a simpler structure than properties, as they do not require the read/write distinction. To extend $$SDF-ACTION-PROTOCOL-MAP for a new protocol, implementers MUST add a group entry that maps the protocol name to the protocol-specific attributes. For example, an extension for a fictitious "new-protocol" could be defined as:¶

$$SDF-ACTION-PROTOCOL-MAP //= (
  "new-protocol": new-protocol-action
)

new-protocol-action = {
  commandID: uint
}

Figure 9: Example Action Protocol Map Extension

An SDF model using this extension could look like:¶

{
  "sdfAction": {
    "reset": {
      "sdfProtocolMap": {
        "new-protocol": {
          "commandID": 42
        }
      }
    }
  }
}

Figure 10: Example Action Protocol Map in JSON

3.1.3. Event Extension

The $$SDF-EXTENSION-EVENT group socket in the eventqualities rule of Appendix A of [RFC9880] is used to add protocol mapping to sdfEvent definitions:¶

$$SDF-EXTENSION-EVENT //= (
  sdfProtocolMap: {
    * $$SDF-EVENT-PROTOCOL-MAP
  }
)

Figure 11: SDF Event Extension Point for Protocol Mapping

Events follow the same simple pattern as actions. To extend $$SDF-EVENT-PROTOCOL-MAP for a new protocol, implementers add a group entry that maps the protocol name to the protocol-specific attributes. For example, an extension for a fictitious "new-protocol" could be defined as:¶

$$SDF-EVENT-PROTOCOL-MAP //= (
  "new-protocol": new-protocol-event
)

new-protocol-event = {
  eventID: uint
}

Figure 12: Example Event Protocol Map Extension

An SDF model using this extension could look like:¶

{
  "sdfEvent": {
    "alert": {
      "sdfProtocolMap": {
        "new-protocol": {
          "eventID": 3
        }
      }
    }
  }
}

Figure 13: Example Event Protocol Map in JSON

4. Registered Protocol Mappings

This section defines the protocol mappings registered by this document.¶

4.1. BLE

The BLE protocol mapping allows SDF models to specify how properties and events should be accessed using Bluetooth Low Energy (BLE) protocol [BLE53]. The mapping includes details such as service IDs and characteristic IDs that are used to access the corresponding SDF affordances.¶

4.1.1. Properties

For sdfProperty, the BLE protocol mapping structure is defined as follows:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"ble", ble-property, ble-property, ble-\
                                                            property>
)

ble-property = {
  serviceID: text,
  characteristicID: text
}

Figure 14: CDDL definition for BLE Protocol Mapping for sdfProperty

Where:¶

serviceID is the BLE service ID that corresponds to the SDF property.¶
characteristicID is the BLE characteristic ID that corresponds to the SDF property.¶

For example, a BLE protocol mapping for a temperature property:¶

{
  "sdfProperty": {
    "temperature": {
      "sdfProtocolMap": {
        "ble": {
          "serviceID": "00001809-0000-1000-8000-00805f9b34fb",
          "characteristicID": "00002a1c-0000-1000-8000-00805f9b34fb"
        }
      }
    }
  }
}

For a temperature property that has different mappings for read and write operations, here is an example of the BLE protocol mapping:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
  "sdfProperty": {
    "temperature": {
      "sdfProtocolMap": {
        "ble": {
          "read": {
            "serviceID": "00001809-0000-1000-8000-00805f9b34fb",
            "characteristicID": "00002a1c-0000-1000-8000-\
                                                        00805f9b34fb"
          },
          "write": {
            "serviceID": "00001809-0000-1000-8000-00805f9b34fb",
            "characteristicID": "00002a51-0000-1000-8000-\
                                                        00805f9b34fb"
          }
        }
      }
    }
  }
}

4.1.2. Events

For sdfEvents, the BLE protocol mapping structure is similar to sdfProperties, but it MUST additionally include at least the type of the event.¶

$$SDF-EVENT-PROTOCOL-MAP //= (
  ble: ble-event-map
)

ble-event-map = {
  type: "gatt",
  serviceID: text,
  characteristicID: text
} / { type: "advertisements" } / { type: "connection_events" }

Figure 15: BLE Protocol Mapping for sdfEvents

Where:¶

type specifies the type of BLE event, such as "gatt" for GATT events, "advertisements" for advertisement events, or "connection_events" for connection-related events.¶
serviceID and characteristicID identify the GATT service and characteristic. They MUST be present when type is "gatt", and MUST be absent when type is "advertisements" or "connection_events".¶

For example, a BLE event mapping for a heart rate measurement event:¶

{
  "sdfEvent": {
    "heartRate": {
      "sdfProtocolMap": {
        "ble": {
          "type": "gatt",
          "serviceID": "0000180d-0000-1000-8000-00805f9b34fb",
          "characteristicID": "00002a37-0000-1000-8000-00805f9b34fb"
        }
      }
    }
  }
}

Here is an example of an isPresent event using BLE advertisements:¶

{
  "sdfEvent": {
    "isPresent": {
      "sdfProtocolMap": {
        "ble": {
          "type": "advertisements"
        }
      }
    }
  }
}

4.2. Zigbee

The Zigbee protocol mapping allows SDF models to specify how properties, actions, and events should be accessed using the Zigbee protocol [Zigbee30]. The mapping includes details such as cluster IDs and attribute IDs that are used to access the corresponding SDF affordances.¶

4.2.1. Properties

An sdfProperty is mapped to a Zigbee cluster attribute. The Zigbee property protocol mapping structure is defined as follows:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"zigbee", zigbee-property, zigbee-property, \
                                                     zigbee-property>
)

zigbee-property = {
  endpointID: uint,
  clusterID: uint,
  attributeID: uint,
  attributeType: uint,
  ? profileID: uint,
  ? manufacturerCode: uint,
}

Figure 16: CDDL definition for Zigbee Protocol Mapping for sdfProperty

Where:¶

endpointID is the Zigbee endpoint ID that corresponds to the SDF property.¶
clusterID is the Zigbee cluster ID that corresponds to the SDF property.¶
attributeID is the Zigbee attribute ID that corresponds to the SDF property.¶
attributeType is the Zigbee data type of the attribute, as defined by the Zigbee Cluster Library [ZCL7].¶
profileID is the Zigbee application profile ID (optional). If not provided, it defaults to the Home Automation profile (0x0104), which is the default application profile defined in [Zigbee30].¶
manufacturerCode is the Zigbee manufacturer code of the attribute (optional).¶

For example, a Zigbee protocol mapping for a temperature property may look as follows:¶

{
  "sdfProperty": {
    "temperature": {
      "sdfProtocolMap": {
        "zigbee": {
          "endpointID": 1,
          "clusterID": 1026,
          "attributeID": 0,
          "attributeType": 41,
          "profileID": 260
        }
      }
    }
  }
}

4.2.2. Events

An sdfEvent is mapped to a Zigbee cluster event such as attribute reporting or a device-initiated write to an attribute on the gateway. The Zigbee event protocol mapping structure is defined as follows. The "attribute_reporting" and "write_event" variants reuse the zigbee-property definition from Figure 16 to identify the underlying Zigbee attribute:¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-EVENT-PROTOCOL-MAP //= (
  zigbee: zigbee-event-map
)

zigbee-event-map = zigbee-attribute-reporting / zigbee-write-event \
                                            / zigbee-connection-event

zigbee-attribute-reporting = {
  type: "attribute_reporting",
  ~zigbee-property,
  ? minReportingInterval: uint,
  ? maxReportingInterval: uint,
  ? reportableChange: number,
}

zigbee-write-event = {
  type: "write_event",
  ~zigbee-property,
}

zigbee-connection-event = {
  type: "connection_events",
}

Figure 17: CDDL definition for Zigbee Protocol Mapping for sdfEvents

Where:¶

type is the type of Zigbee event. It MUST be one of:¶
- "attribute_reporting": the event is triggered by Zigbee attribute reporting.¶
- "write_event": the event is triggered by the device writing to an attribute on the gateway.¶
- "connection_events": the event is triggered when a Zigbee end device joins or leaves the Zigbee network.¶
endpointID, clusterID, attributeID, attributeType, profileID, and manufacturerCode have the same meaning as described for sdfProperty in Figure 16. These fields are present when type is "attribute_reporting" or "write_event", and MUST be absent when type is "connection_events".¶
minReportingInterval is the minimum reporting interval in seconds (optional). It is the minimum time between issued attribute reports and only applies when type is "attribute_reporting".¶
maxReportingInterval is the maximum reporting interval in seconds (optional). It is the maximum time between issued attribute reports and only applies when type is "attribute_reporting".¶
reportableChange is the minimum change to the attribute value that triggers a report (optional). It only applies when type is "attribute_reporting" and to attributes whose attributeType is one of the "analog" data types defined by the Zigbee Cluster Library [ZCL7] (e.g., unsigned and signed integers, floating point numbers), as opposed to "discrete" data types (e.g., booleans, enumerations, bitmaps), for which reporting a minimum change is not meaningful. The value is interpreted in the same Zigbee data type as the reported attribute's attributeType.¶

For example, a Zigbee event mapping for a temperature change report:¶

{
  "sdfEvent": {
    "temperatureChange": {
      "sdfProtocolMap": {
        "zigbee": {
          "type": "attribute_reporting",
          "profileID": 260,
          "endpointID": 1,
          "clusterID": 1026,
          "attributeID": 0,
          "attributeType": 41,
          "minReportingInterval": 10,
          "maxReportingInterval": 300,
          "reportableChange": 50
        }
      }
    }
  }
}

Here is an example of an isPresent event using Zigbee connection events:¶

{
  "sdfEvent": {
    "isPresent": {
      "sdfProtocolMap": {
        "zigbee": {
          "type": "connection_events"
        }
      }
    }
  }
}

4.2.3. Actions

An sdfAction is mapped to a Zigbee cluster command. The Zigbee protocol mapping structure for actions is defined as follows:¶

$$SDF-ACTION-PROTOCOL-MAP //= (
  zigbee: zigbee-action-map
)

zigbee-action-map = {
  endpointID: uint,
  clusterID: uint,
  commandID: uint,
  ? profileID: uint,
  ? manufacturerCode: uint,
}

Figure 18: CDDL definition for Zigbee Protocol Mapping for sdfAction

Where:¶

endpointID is the Zigbee endpoint ID that corresponds to the SDF action.¶
clusterID is the Zigbee cluster ID that corresponds to the SDF action.¶
commandID is the Zigbee command ID that corresponds to the SDF action.¶
profileID has the same meaning and default as described for sdfProperty in Figure 16 (optional).¶
manufacturerCode is the Zigbee manufacturer code of the command (optional).¶

For example, a Zigbee protocol mapping to set a temperature:¶

{
  "sdfAction": {
    "setTemperature": {
      "sdfProtocolMap": {
        "zigbee": {
          "profileID": 260,
          "endpointID": 1,
          "clusterID": 1026,
          "commandID": 0
        }
      }
    }
  }
}

5. SCIM SDF Extension

While SDF provides a way to describe a device class and SCIM defines a device instance, a method is needed to associate a mapping between an instance of a device and its associated SDF models. To accomplish so, this document defines a SCIM extension that MAY be used in conjunction with [RFC9944] in Figure 19. Implementation of this SCIM extension is OPTIONAL and independent of the protocol mapping functionality defined in the rest of this document. The SCIM schema attributes used here are described in Section 7 of [RFC7643].¶

=============== NOTE: '\' line wrapping per RFC 8792 ================

{
    "id": "urn:ietf:params:scim:schemas:extension:sdf:2.0:Device",
    "name": "SDFExtension",
    "description": "Device extension schema for SDF.",
    "attributes": [
        {
            "name": "sdf",
            "type": "string",
            "description": "SDF models supported by the device.",
            "multiValued": true,
            "required": true,
            "caseExact": true,
            "mutability": "readWrite",
            "returned": "default",
            "uniqueness": "none"
        }
    ],
    "meta": {
        "resourceType": "Schema",
        "location": "/v2/Schemas/urn:ietf:params:scim:schemas:\
                                            extension:sdf:2.0:Device"
    }
}

Figure 19: SCIM SDF Extension Schema

Here is an example SCIM device schema extension with SDF models:¶

{
    "schemas": [
        "urn:ietf:params:scim:schemas:core:2.0:Device",
        "urn:ietf:params:scim:schemas:extension:sdf:2.0:Device"
    ],
    "id": "e9e30dba-f08f-4109-8486-d5c6a3316111",
    "displayName": "Heart Monitor",
    "active": true,
    "urn:ietf:params:scim:schemas:extension:sdf:2.0:Device": {
        "sdf": [
            "https://example.com/thermometer#/sdfThing/thermometer",
            "https://example.com/heartrate#/sdfObject/healthsensor"
        ]
    }
}

An SDF model MUST be referenced with the sdf keyword inside the SCIM device schema as described in [RFC9944].¶

6. Implementation Status

This section is to be removed before publishing as an RFC.¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

6.1. TieDie IoT

Organization: Cisco Systems, North Carolina State University¶

Description: Open-source implementation of a gateway and SDKs that implement the SDF Protocol Mapping for BLE.¶

Level of maturity: Open-source prototype¶

Coverage: All SDF Protocol Mappings for BLE¶

Version compatibility: draft-11¶

Licensing: Apache License, Version 2.0¶

URL: https://github.com/iot-onboarding/tiedie¶

6.2. Cisco Sensor Connect for IoT Services

Organization: Cisco Systems¶

Description: Commercial solution that delivers advanced BLE capabilities over Cisco Wireless infrastructure.¶

Level of maturity: Production¶

Coverage: All SDF Protocol Mappings for BLE and Zigbee¶

Version compatibility: draft-11¶

Licensing: Proprietary¶

7. Security Considerations

The security considerations of [RFC9880] apply to this document as well.¶

Each protocol mapped using this mechanism has its own security model. The protocol mapping mechanism defined in this document does not provide additional security beyond what is offered by the underlying protocols. Implementations MUST ensure that appropriate protocol-level security mechanisms are employed when accessing affordances through the mapped protocol operations.¶

8. IANA Considerations

This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to this document, in accordance with [RFC8126].¶

8.1. Protocol Mapping

IANA is requested to create a new registry called "SDF Protocol Mapping" in the "Semantic Definition Format (SDF)" registry group [IANA.sdf], with the following template:¶

Protocol map name, as per sdfProtocolMap¶
Protocol name¶
Description¶
Reference of the specification describing the protocol mapping.¶

The registration policy for this registry is "Specification Required" as defined in Section 4.6 of [RFC8126]. Protocol names used as keys in the sdfProtocolMap object (e.g., "ble", "zigbee") are registered in this registry.¶

The specification describing a new SDF protocol mapping is expected to include:¶

A CDDL definition that extends at least one of the group sockets defined in this document: $$SDF-PROPERTY-PROTOCOL-MAP (Section 3.1.1), $$SDF-ACTION-PROTOCOL-MAP (Section 3.1.2), or $$SDF-EVENT-PROTOCOL-MAP (Section 3.1.3). Property mappings use the property-protocol-map generic (Section 3.1.1) to ensure a consistent structure.¶
A description of the protocol-specific attributes introduced by the CDDL extension, including their semantics and how they relate to the underlying protocol operations.¶

The designated expert(s) verify that the specification meets the above requirements, and that the protocol map name is appropriately named and unlikely to cause confusion.¶

The registrant of an existing entry may request updates to that entry, subject to the same expert review. They should verify that updates preserve backward compatibility with deployed implementations, or if breaking changes are necessary, consider whether a new registry entry is more appropriate.¶

The following protocol mappings are described in this document:¶

Table 1: Protocol Mapping Registry
Protocol Map Name	Protocol Name	Description	Reference
ble	Bluetooth Low Energy (BLE)	Protocol mapping for BLE devices	This document, Section 4.1
zigbee	Zigbee	Protocol mapping for Zigbee devices	This document, Section 4.2

8.2. SCIM Device Schema SDF Extension

IANA is requested to create the following extension in the "SCIM Server-Related Schema URIs" registry, within the "System for Cross-domain Identity Management (SCIM) Schema URIs" registry group [IANA.scim], as described in Section 5:¶

Table 2: SCIM Device Schema SDF Extension
URN	Description	Resource Type	Reference
urn:ietf:params:scim: schemas:extension: sdf:2.0:Device	SDF Extension	Device	This document, Section 5

9. References

9.1. Normative References

[BLE53]: Bluetooth SIG, "Bluetooth Core Specification Version 5.3", 13 July 2021, <https://www.bluetooth.com/specifications/specs/core-specification-5-3/>.
[IANA.scim]: IANA, "System for Cross-domain Identity Management (SCIM) Schema URIs", <https://www.iana.org/assignments/scim>.
[IANA.sdf]: IANA, "Semantic Definition Format (SDF)", <https://www.iana.org/assignments/sdf>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC7643]: Hunt, P., Ed., Grizzle, K., Wahlstroem, E., and C. Mortimore, "System for Cross-domain Identity Management: Core Schema", RFC 7643, DOI 10.17487/RFC7643, September 2015, <https://www.rfc-editor.org/rfc/rfc7643>.
[RFC8126]: Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/rfc/rfc8126>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC8610]: Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/rfc/rfc8610>.
[RFC9880]: Koster, M., Ed., Bormann, C., Ed., and A. Keränen, "Semantic Definition Format (SDF) for Data and Interactions of Things", RFC 9880, DOI 10.17487/RFC9880, January 2026, <https://www.rfc-editor.org/rfc/rfc9880>.
[RFC9944]: Shahzad, M., Iqbal, H., and E. Lear, "Device Schema Extensions to the System for Cross-Domain Identity Management (SCIM) Model", RFC 9944, DOI 10.17487/RFC9944, May 2026, <https://www.rfc-editor.org/rfc/rfc9944>.
[ZCL7]: Connectivity Standards Alliance, "Zigbee Cluster Library Specification", CSA Document 07-5123 (Revision 7), February 2018, <https://csa-iot.org/wp-content/uploads/2022/01/07-5123-07-zigbeeclusterlibrary_revision_7-1.pdf>.
[Zigbee30]: Connectivity Standards Alliance, "Zigbee Specification", CSA Document 05-3474-23 (Revision R23.1), July 2024, <https://csa-iot.org/wp-content/uploads/2024/07/docs-05-3474-23-csg-zigbee-specificationR23.1.pdf>.

9.2. Informative References

[RFC7252]: Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/rfc/rfc7252>.
[RFC7942]: Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/rfc/rfc7942>.
[RFC9110]: Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/rfc/rfc9110>.

Appendix A. CDDL Definition

This appendix contains the combined CDDL definitions for the SDF protocol mappings.¶

<CODE BEGINS> file "sdf-protocol-map.cddl"

=============== NOTE: '\' line wrapping per RFC 8792 ================

$$SDF-EXTENSION-PROPERTY //= (
  sdfProtocolMap: {
    * $$SDF-PROPERTY-PROTOCOL-MAP
  }
)

property-protocol-map<name, props, read-props, write-props> = (
  name => props /
    {
      read: read-props,
      write: write-props
    }
)

$$SDF-EXTENSION-ACTION //= (
  sdfProtocolMap: {
    * $$SDF-ACTION-PROTOCOL-MAP
  }
)

$$SDF-EXTENSION-EVENT //= (
  sdfProtocolMap: {
    * $$SDF-EVENT-PROTOCOL-MAP
  }
)

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"ble", ble-property, ble-property, ble-\
                                                            property>
)

ble-property = {
  serviceID: text,
  characteristicID: text
}

$$SDF-EVENT-PROTOCOL-MAP //= (
  ble: ble-event-map
)

ble-event-map = {
  type: "gatt",
  serviceID: text,
  characteristicID: text
} / { type: "advertisements" } / { type: "connection_events" }

$$SDF-PROPERTY-PROTOCOL-MAP //= (
  property-protocol-map<"zigbee", zigbee-property, zigbee-property, \
                                                     zigbee-property>
)

zigbee-property = {
  endpointID: uint,
  clusterID: uint,
  attributeID: uint,
  attributeType: uint,
  ? profileID: uint,
  ? manufacturerCode: uint,
}

$$SDF-EVENT-PROTOCOL-MAP //= (
  zigbee: zigbee-event-map
)

zigbee-event-map = zigbee-attribute-reporting / zigbee-write-event \
                                            / zigbee-connection-event

zigbee-attribute-reporting = {
  type: "attribute_reporting",
  ~zigbee-property,
  ? minReportingInterval: uint,
  ? maxReportingInterval: uint,
  ? reportableChange: number,
}

zigbee-write-event = {
  type: "write_event",
  ~zigbee-property,
}

zigbee-connection-event = {
  type: "connection_events",
}

$$SDF-ACTION-PROTOCOL-MAP //= (
  zigbee: zigbee-action-map
)

zigbee-action-map = {
  endpointID: uint,
  clusterID: uint,
  commandID: uint,
  ? profileID: uint,
  ? manufacturerCode: uint,
}


<CODE ENDS>

Figure 20: CDDL for SDF protocol mappings

Appendix B. OpenAPI Definition

The following non-normative model is provided for convenience of the implementer.¶

<CODE BEGINS> file "ProtocolMap.yaml"

=============== NOTE: '\' line wrapping per RFC 8792 ================

openapi: 3.0.3
info:
  title: SDF Protocol Mapping
  description: |-
    SDF Protocol Mapping. When adding a
    new protocol mapping please add a reference to the protocol map
    for all the schemas in this file.
  version: 0.10.0
externalDocs:
  description: SDF Protocol Mapping IETF draft
  url: https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf-protocol\
                                                            -mapping/

paths: {}

components:
  schemas:
## Protocol Map for a property
    ProtocolMap-Property:
      type: object
      properties:
        sdfProtocolMap:
          oneOf:
            - $ref: './ProtocolMap-BLE.yaml#/components/schemas/\
                                             ProtocolMap-BLE-Propmap'
            - $ref: './ProtocolMap-Zigbee.yaml#/components/schemas/\
                                          ProtocolMap-Zigbee-Propmap'

## Protocol Map for an event
    ProtocolMap-Event:
      type: object
      properties:
        sdfProtocolMap:
          oneOf:
            - $ref: './ProtocolMap-BLE.yaml#/components/schemas/\
                                               ProtocolMap-BLE-Event'
            - $ref: './ProtocolMap-Zigbee.yaml#/components/schemas/\
                                            ProtocolMap-Zigbee-Event'

## Protocol Map for an action
    ProtocolMap-Action:
      type: object
      properties:
        sdfProtocolMap:
          oneOf:
            - $ref: './ProtocolMap-Zigbee.yaml#/components/schemas/\
                                           ProtocolMap-Zigbee-Action'


<CODE ENDS>

Figure 21: OpenAPI model

B.1. Protocol map for BLE

<CODE BEGINS> file "ProtocolMap-BLE.yaml"

=============== NOTE: '\' line wrapping per RFC 8792 ================

openapi: 3.0.3
info:
  title: SDF Protocol Mapping for BLE
  description: |-
    SDF Protocol Mapping for BLE devices.
  version: 0.10.0
externalDocs:
  description: SDF Protocol Mapping IETF draft
  url: https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf-protocol\
                                                            -mapping/

paths: {}

components:
  schemas:
## Protocol Mapping for BLE Property
    ProtocolMap-BLE-Propmap:
      required:
        - ble
      type: object
      properties:
        ble:
          oneOf:
            - $ref: '#/components/schemas/BLE-Property'
            - type: object
              required:
                - read
                - write
              properties:
                read:
                  $ref: '#/components/schemas/BLE-Property'
                write:
                  $ref: '#/components/schemas/BLE-Property'

## Reusable BLE property object
    BLE-Property:
      required:
        - serviceID
        - characteristicID
      type: object
      properties:
        serviceID:
          type: string
          format: uuid
          example: 00001809-0000-1000-8000-00805f9b34fb
        characteristicID:
          type: string
          format: uuid
          example: 00002a1c-0000-1000-8000-00805f9b34fb

## Defines different types of BLE events
    ProtocolMap-BLE-Event:
      required:
        - ble
      type: object
      properties:
        ble:
          oneOf:
            - type: object
              required:
                - type
                - serviceID
                - characteristicID
              properties:
                type:
                  type: string
                  example: gatt
                  enum:
                    - gatt
                serviceID:
                  type: string
                  example: 00001809-0000-1000-8000-00805f9b34fb
                characteristicID:
                  type: string
                  example: 00002a1c-0000-1000-8000-00805f9b34fb
            - type: object
              required:
                - type
              properties:
                type:
                  type: string
                  example: advertisements
                  enum:
                    - advertisements
            - type: object
              required:
                - type
              properties:
                type:
                  type: string
                  example: connection_events
                  enum:
                    - connection_events

<CODE ENDS>

Figure 22: OpenAPI model for BLE

B.2. Protocol map for Zigbee

<CODE BEGINS> file "ProtocolMap-Zigbee.yaml"

=============== NOTE: '\' line wrapping per RFC 8792 ================

openapi: 3.0.3
info:
  title: SDF Protocol Mapping for Zigbee
  description: |-
    SDF Protocol Mapping for Zigbee devices.
  version: 0.10.0
externalDocs:
  description: SDF Protocol Mapping IETF draft
  url: https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf-protocol\
                                                            -mapping/

paths: {}

components:
  schemas:
## Protocol mapping for Zigbee property
    ProtocolMap-Zigbee-Propmap:
      required:
        - zigbee
      type: object
      properties:
        zigbee:
          oneOf:
            - $ref: '#/components/schemas/Zigbee-Property'
            - type: object
              required:
                - read
                - write
              properties:
                read:
                  $ref: '#/components/schemas/Zigbee-Property'
                write:
                  $ref: '#/components/schemas/Zigbee-Property'

## Reusable Zigbee property object
    Zigbee-Property:
      required:
        - endpointID
        - clusterID
        - attributeID
        - attributeType
      type: object
      properties:
        endpointID:
          type: integer
          format: int32
          example: 1
        clusterID:
          type: integer
          format: int32
          example: 6
        attributeID:
          type: integer
          format: int32
          example: 16
        attributeType:
          type: integer
          format: int32
          example: 32
        profileID:
          type: integer
          format: int32
          example: 260
        manufacturerCode:
          type: integer
          format: int32
          example: 4174

    ProtocolMap-Zigbee-Event:
      required:
        - zigbee
      type: object
      properties:
        zigbee:
          oneOf:
            - type: object
              required:
                - type
                - endpointID
                - clusterID
                - attributeID
                - attributeType
              properties:
                type:
                  type: string
                  example: attribute_reporting
                  enum:
                    - attribute_reporting
                endpointID:
                  type: integer
                  format: int32
                  example: 1
                clusterID:
                  type: integer
                  format: int32
                  example: 6
                attributeID:
                  type: integer
                  format: int32
                  example: 16
                attributeType:
                  type: integer
                  format: int32
                  example: 41
                profileID:
                  type: integer
                  format: int32
                  example: 260
                manufacturerCode:
                  type: integer
                  format: int32
                minReportingInterval:
                  type: integer
                  format: int32
                  example: 10
                maxReportingInterval:
                  type: integer
                  format: int32
                  example: 300
                reportableChange:
                  type: number
                  example: 50
            - type: object
              required:
                - type
                - endpointID
                - clusterID
                - attributeID
                - attributeType
              properties:
                type:
                  type: string
                  example: write_event
                  enum:
                    - write_event
                endpointID:
                  type: integer
                  format: int32
                  example: 1
                clusterID:
                  type: integer
                  format: int32
                  example: 6
                attributeID:
                  type: integer
                  format: int32
                  example: 16
                attributeType:
                  type: integer
                  format: int32
                  example: 41
                profileID:
                  type: integer
                  format: int32
                  example: 260
                manufacturerCode:
                  type: integer
                  format: int32
            - type: object
              required:
                - type
              properties:
                type:
                  type: string
                  example: connection_events
                  enum:
                    - connection_events

## Protocol mapping for Zigbee action
    ProtocolMap-Zigbee-Action:
      required:
        - zigbee
      type: object
      properties:
        zigbee:
          required:
            - endpointID
            - clusterID
            - commandID
          type: object
          properties:
            endpointID:
              type: integer
              format: int32
              example: 1
            clusterID:
              type: integer
              format: int32
              example: 6
            commandID:
              type: integer
              format: int32
              example: 0
            profileID:
              type: integer
              format: int32
              example: 260
            manufacturerCode:
              type: integer
              format: int32
              example: 4174

<CODE ENDS>

Figure 23: OpenAPI model for Zigbee

Acknowledgements

This document relies on SDF models described in [RFC9880], as such, we are grateful to the authors of this document for putting their time and effort into defining SDF in depth, allowing us to make use of it. The authors are grateful to Carsten Bormann, Jan Romann, Ari Keränen, and Eliot Lear for their reviews and contributions to this document, in particular Jan Romann for his help with the CDDL definitions (Figure 20) and Eliot Lear for his contributions to Section 5.¶

Authors' Addresses

Rohit Mohan

Cisco Systems

170 West Tasman Drive

San Jose, 95134

United States of America

Email: rohitmo@cisco.com

Bart Brinckman

Cisco Systems

170 West Tasman Drive

San Jose, 95134

United States of America

Email: bbrinckm@cisco.com

Lorenzo Corneo

Ericsson

Hirsalantie 11

FI-1296 Jorvas

Finland

Email: lorenzo.corneo@ericsson.com

SDF Protocol Mapping

Abstract

About This Document

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction

2. Conventions and Definitions

3. SDF Protocol Mapping Structure

3.1. SDF Extension Points

3.1.1. Property Extension

3.1.2. Action Extension

3.1.3. Event Extension

4. Registered Protocol Mappings

4.1. BLE

4.1.1. Properties

4.1.2. Events

4.2. Zigbee

4.2.1. Properties

4.2.2. Events

4.2.3. Actions

5. SCIM SDF Extension

6. Implementation Status

6.1. TieDie IoT

6.2. Cisco Sensor Connect for IoT Services

7. Security Considerations

8. IANA Considerations

8.1. Protocol Mapping

8.2. SCIM Device Schema SDF Extension

9. References

9.1. Normative References

9.2. Informative References

Appendix A. CDDL Definition

Appendix B. OpenAPI Definition

B.1. Protocol map for BLE

B.2. Protocol map for Zigbee

Acknowledgements

Authors' Addresses