



A Semantic Definition Format for Data and Interactions of ThingsR. Mohan
Internet-Draft                                              B. Brinckman
Intended status: Standards Track                           Cisco Systems
Expires: 28 August 2026                                        L. Corneo
                                                                Ericsson
                                                        24 February 2026


                        Protocol Mapping for SDF
                draft-ietf-asdf-sdf-protocol-mapping-05

Abstract

   This document defines protocol mapping extensions for the Semantic
   Definition Format (SDF) to enable mapping of protocol-agnostic SDF
   affordances to protocol-specific operations.  The protocol mapping
   mechanism allows SDF models to specify how properties, actions, and
   events should be accessed using specific non-IP and IP protocols such
   as Bluetooth Low Energy, Zigbee or HTTP and CoAP.  This document also
   describes a method to extend SCIM with an SDF model mapping.

About This Document

   This note is to be removed before publishing as an RFC.

   Status information for this document may be found at
   https://datatracker.ietf.org/doc/draft-ietf-asdf-sdf-protocol-
   mapping/.

   Discussion of this document takes place on the A Semantic Definition
   Format for Data and Interactions of Things Working Group mailing list
   (mailto:asdf@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/browse/asdf/.  Subscribe at
   https://www.ietf.org/mailman/listinfo/asdf/.

   Source for this draft and an issue tracker can be found at
   https://github.com/ietf-wg-asdf/sdf-protocol-mapping.

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/.




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


   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 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Protocol Mapping  . . . . . . . . . . . . . . . . . . . .   3
     1.2.  SCIM SDF model extension  . . . . . . . . . . . . . . . .   3
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   3.  Structure . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  SDF Extension Points  . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Property Extension  . . . . . . . . . . . . . . . . .   5
       3.1.2.  Action Extension  . . . . . . . . . . . . . . . . . .   7
       3.1.3.  Event Extension . . . . . . . . . . . . . . . . . . .   8
     3.2.  Protocol Registration . . . . . . . . . . . . . . . . . .   9
   4.  Registered Protocol Mappings  . . . . . . . . . . . . . . . .  10
     4.1.  BLE . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
       4.1.1.  Properties  . . . . . . . . . . . . . . . . . . . . .  10
       4.1.2.  Events  . . . . . . . . . . . . . . . . . . . . . . .  11
     4.2.  Zigbee  . . . . . . . . . . . . . . . . . . . . . . . . .  13
       4.2.1.  Properties  . . . . . . . . . . . . . . . . . . . . .  13
       4.2.2.  Events  . . . . . . . . . . . . . . . . . . . . . . .  14
       4.2.3.  Actions . . . . . . . . . . . . . . . . . . . . . . .  15
   5.  SCIM SDF Extension  . . . . . . . . . . . . . . . . . . . . .  16
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  18
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Protocol Mapping  . . . . . . . . . . . . . . . . . . . .  18
     7.2.  SCIM Device Schema SDF Extension  . . . . . . . . . . . .  19
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  19
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  19



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


     8.2.  Informative References  . . . . . . . . . . . . . . . . .  20
   Appendix A.  CDDL Definition  . . . . . . . . . . . . . . . . . .  21
   Appendix B.  OpenAPI Definition . . . . . . . . . . . . . . . . .  22
     B.1.  Protocol map for BLE  . . . . . . . . . . . . . . . . . .  23
     B.2.  Protocol map for Zigbee . . . . . . . . . . . . . . . . .  25
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26

1.  Introduction

1.1.  Protocol Mapping

   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).
   When implementing the SDF model for a device on an actual
   implementation using specific communication protocols, there needs to
   be a mechanism to map the protocol-agnostic SDF definitions to
   protocol-specific operations, translating the model into a real-world
   implementation.

   This document defines such a mechanism using the sdfProtocolMap
   keyword, which allows SDF models to include protocol-specific mapping
   information attached to the protocol-agnostic definitions.  An
   sdfProtocolMap can be applied to an sdfAffordance, 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.

   The protocol mapping mechanism is designed to be extensible: target
   protocols include non-IP protocols commonly used in IoT environments,
   such as [BLE53] and [Zigbee30], as well as IP-based protocols such as
   HTTP [RFC9110] or CoAP [RFC7252].  This document registers mappings
   for BLE and Zigbee; future specifications can define mappings for
   additional protocols.

1.2.  SCIM SDF model extension

   SDF provides a way to describe a class of devices and SCIM describes
   a device instance.  The SDF model extension in this document defines
   a SCIM extension that enables inclusion of the SDF model for the
   class of devices a device belongs to in the SCIM object for that
   device.






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


2.  Conventions and Definitions

   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.  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.

   A protocol mapping object is a JSON object identified by the
   sdfProtocolMap keyword, nested inside an SDF affordance definition
   (sdfProperty, sdfAction, or sdfEvent).  Protocol-specific attributes
   are embedded within this object, keyed by an IANA registered protocol
   name, e.g., "ble" or "zigbee".

   sdfProperty / sdfAction / sdfEvent
     |
     +-----> sdfProtocolMap
               |
               +-----> ble
               |        |
               |        +--> BLE-specific mapping
               |
               +-----> zigbee
               |        |
               |        +--> Zigbee-specific mapping
               |
               +-----> ...

                    Figure 1: Protocol Mapping Structure

3.1.  SDF Extension Points

   The sdfProtocolMap keyword is introduced into SDF affordance
   definitions through the extension points defined in the formal syntax
   of [RFC9880] (Appendix A).  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.





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


   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 [RFC9880] (Appendix A) is used to add protocol mapping to
   sdfProperty definitions:

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

   property-protocol-map<name, props> = (
     name => props /
       {
         read: props,
         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
   registered 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 extend $$SDF-PROPERTY-PROTOCOL-MAP for a new protocol (e.g., "new-
   protocol"), use the property-protocol-map generic with the protocol
   name and a map type defining the protocol-specific attributes.  The
   protocol name ("new-protocol") MUST be registered in the IANA
   registry defined in Section 7.1.

   For example:







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


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

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

             Figure 3: Example Property Protocol Map Extension

   The corresponding JSON in an SDF model looks like:

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

              Figure 4: Example Property Protocol Map in JSON

   When a property uses different protocol attributes for read and write
   operations, the mapping can be split:



















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


   {
     "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 Read/Write in JSON

3.1.2.  Action Extension

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

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

         Figure 6: 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, add a group entry mapping the protocol name
   to the protocol-specific attributes:










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


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

   new-protocol-action = {
     commandID: uint
   }

              Figure 7: Example Action Protocol Map Extension

   The corresponding JSON in an SDF model would look like:

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

               Figure 8: Example Action Protocol Map in JSON

3.1.3.  Event Extension

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

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

          Figure 9: 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:









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


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

   new-protocol-event = {
     eventID: uint
   }

              Figure 10: Example Event Protocol Map Extension

   The corresponding JSON in an SDF model looks like:

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

               Figure 11: Example Event Protocol Map in JSON

3.2.  Protocol Registration

   Protocol names used as keys in the sdfProtocolMap object (e.g.,
   "ble", "zigbee") MUST be registered in the IANA registry defined in
   Section 7.1.

   A new protocol mapping MUST be defined by a specification that
   includes:

   *  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
      SHOULD 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.






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


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.  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 SDF properties, the BLE protocol mapping structure is defined as
   follows:

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

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

     Figure 12: CDDL definition for BLE Protocol Mapping for properties

   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:













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


   {
     "sdfProperty": {
       "temperature": {
         "sdfProtocolMap": {
           "ble": {
             "serviceID": "12345678-1234-5678-1234-56789abcdef4",
             "characteristicID": "12345678-1234-5678-1234-56789abcdef5"
           }
         }
       }
     }
   }

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

   {
     "sdfProperty": {
       "temperature": {
         "sdfProtocolMap": {
           "ble": {
             "read": {
               "serviceID": "12345678-1234-5678-1234-56789abcdef4",
               "characteristicID": "12345678-1234-5678-1234-56789abcdef5"
             },
             "write": {
               "serviceID": "12345678-1234-5678-1234-56789abcdef4",
               "characteristicID": "12345678-1234-5678-1234-56789abcdef6"
             }
           }
         }
       }
     }
   }

4.1.2.  Events

   For SDF events, the BLE protocol mapping structure is similar to SDF
   properties, but it must include additional attributes such as the
   type of the event.











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


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

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

                 Figure 13: BLE Protocol Mapping for events

   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 are optional attributes that are
      specified if the type is "gatt".

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

   {
     "sdfEvent": {
       "heartRate": {
         "sdfProtocolMap": {
           "ble": {
             "type": "gatt",
             "serviceID": "12345678-1234-5678-1234-56789abcdef4",
             "characteristicID": "12345678-1234-5678-1234-56789abcdef5"
           }
         }
       }
     }
   }

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













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


   {
     "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.  The mapping includes details such as cluster IDs and
   attribute IDs that are used to access the corresponding SDF
   affordances.

4.2.1.  Properties

   SDF properties are mapped to Zigbee cluster attributes.  The Zigbee
   property protocol mapping structure is defined as follows:

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

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

   Figure 14: CDDL definition for Zigbee Protocol Mapping for properties

   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.





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


   *  attributeID is the Zigbee attribute ID that corresponds to the SDF
      property.

   *  attributeType is the Zigbee data type of the attribute.

   *  manufacturerCode is the Zigbee manufacturer code of the attribute
      (optional).

   For example, a Zigbee protocol mapping for a temperature property:

   {
     "sdfProperty": {
       "temperature": {
         "sdfProtocolMap": {
           "zigbee": {
             "endpointID": 1,
             "clusterID": 1026, // 0x0402
             "attributeID": 0, // 0x0000
             "attributeType": 41 // 0x29
           }
         }
       }
     }
   }

4.2.2.  Events

   SDF events are mapped to Zigbee cluster attribute reporting.  The
   Zigbee event protocol mapping structure is defined as follows:

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

   zigbee-event-map = {
     endpointID: uint,
     ? manufacturerCode: uint,
     clusterID: uint,
     attributeID: uint,
     attributeType: uint
   }

     Figure 15: CDDL definition for Zigbee Protocol Mapping for events

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






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


   {
     "sdfEvent": {
       "temperatureChange": {
         "sdfProtocolMap": {
           "zigbee": {
             "endpointID": 1,
             "clusterID": 1026, // 0x0402
             "attributeID": 0, // 0x0000
             "attributeType": 41 // 0x29
           }
         }
       }
     }
   }

4.2.3.  Actions

   SDF actions are mapped to Zigbee cluster commands.  The Zigbee
   protocol mapping structure for actions is defined as follows:

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

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

     Figure 16: CDDL definition for Zigbee Protocol Mapping for actions

   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.

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






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


   {
     "sdfAction": {
       "setTemperature": {
         "sdfProtocolMap": {
           "zigbee": {
             "endpointID": 1,
             "clusterID": 1026, // 0x0402
             "commandID": 0 // 0x0000
           }
         }
       }
     }
   }

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
   this, we define a SCIM extension that can be used in conjunction with
   [I-D.ietf-scim-device-model] in Figure 17.  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].



























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


   =============== 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:extens\
   ion:sdf:2.0:Device"
       }
   }

                    Figure 17: 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 [I-D.ietf-scim-device-model].



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


6.  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.

7.  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].

7.1.  Protocol Mapping

   IANA is requested to create a new registry called "SDF Protocol
   Mapping".

   The registration policy for this registry is "Specification Required"
   as defined in Section 4.6 of [RFC8126].

   The registry must contain the following attributes:

   *  Protocol map name

   *  Protocol name

   *  Description

   *  Reference of the specification describing the protocol mapping.

   The specification requirements for a registration request are defined
   in Section 3.2.

   The designated expert(s) SHOULD verify that the protocol map name is
   appropriate and not likely to cause confusion with existing entries.

   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.




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


   The following protocol mappings are described in this document:

     +==============+===============+====================+===========+
     | Protocol map | Protocol Name | Description        | Reference |
     +==============+===============+====================+===========+
     | ble          | Bluetooth Low | Protocol mapping   | This      |
     |              | Energy (BLE)  | for BLE devices    | document  |
     +--------------+---------------+--------------------+-----------+
     | zigbee       | Zigbee        | Protocol mapping   | This      |
     |              |               | for Zigbee devices | document  |
     +--------------+---------------+--------------------+-----------+

                     Table 1: Protocol Mapping Registry

7.2.  SCIM Device Schema SDF Extension

   IANA is requested to create the following extensions in the SCIM
   Server-Related Schema URIs registry as described in Section 5:

      +=======================+=============+==========+===========+
      | URN                   | Description | Resource | Reference |
      |                       |             | Type     |           |
      +=======================+=============+==========+===========+
      | urn:ietf:params:scim: | SDF         | Device   | This      |
      | schemas:extension:    | Extension   |          | memo,     |
      | sdf:2.0:Device        |             |          | Section 5 |
      +-----------------------+-------------+----------+-----------+

                                 Table 2

8.  References

8.1.  Normative References

   [I-D.ietf-scim-device-model]
              Shahzad, M., Iqbal, H., and E. Lear, "Device Schema
              Extensions to the SCIM model", Work in Progress, Internet-
              Draft, draft-ietf-scim-device-model-18, 3 September 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-scim-
              device-model-18>.

   [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>.






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


   [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>.

8.2.  Informative References

   [BLE53]    Bluetooth SIG, "Bluetooth Core Specification Version 5.3",
              13 July 2021,
              <https://www.bluetooth.com/specifications/specs/core-
              specification-5-3/>.

   [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>.

   [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>.

   [Zigbee30] CSA IoT, "Zigbee 3.0 Specification", 2026,
              <https://csa-iot.org/all-solutions/zigbee/>.







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


Appendix A.  CDDL Definition

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

   <CODE BEGINS> file "sdf-protocol-map.cddl"
   $$SDF-EXTENSION-PROPERTY //= (
     sdfProtocolMap: {
       * $$SDF-PROPERTY-PROTOCOL-MAP
     }
   )

   property-protocol-map<name, props> = (
     name => props /
       {
         read: props,
         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 = {
     serviceID: text,
     characteristicID: text
   }

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

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



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


     ? characteristicID: text
   }

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

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

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

   zigbee-event-map = {
     endpointID: uint,
     ? manufacturerCode: uint,
     clusterID: uint,
     attributeID: uint,
     attributeType: uint
   }

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

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

   <CODE ENDS>

Appendix B.  OpenAPI Definition

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







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


   <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/Prot\
   ocolMap-BLE-Propmap'
               - $ref: './ProtocolMap-Zigbee.yaml#/components/schemas/P\
   rotocolMap-Zigbee-Propmap'

   ## Protocol Map for an event
       ProtocolMap-Event:
         type: object
         properties:
           sdfProtocolMap:
             oneOf:
               - $ref: './ProtocolMap-BLE.yaml#/components/schemas/Prot\
   ocolMap-BLE-Event'
               - $ref: './ProtocolMap-Zigbee.yaml#/components/schemas/P\
   rotocolMap-Zigbee-Event'
   <CODE ENDS>

                                 Figure 18

B.1.  Protocol map for BLE





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


   <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:
             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:
             required:
               - type



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


             type: object
             properties:
               type:
                 type: string
                 example: gatt
                 enum:
                   - gatt
                   - connection_events
                   - advertisements
               serviceID:
                 type: string
                 example: 00001809-0000-1000-8000-00805f9b34fb
               characteristicID:
                 type: string
                 example: 00002a1c-0000-1000-8000-00805f9b34fb
   <CODE ENDS>

                                 Figure 19

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:
             required:
               - endpointID



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


               - clusterID
               - attributeID
             type: object
             properties:
               endpointID:
                 type: integer
                 format: int32
                 example: 1
               clusterID:
                 type: integer
                 format: int32
                 example: 6
               attributeID:
                 type: integer
                 format: int32
                 example: 16
               type:
                 type: integer
                 format: int32
                 example: 1

       ProtocolMap-Zigbee-Event:
         allOf:
           - $ref: '#/components/schemas/ProtocolMap-Zigbee-Propmap'
   <CODE ENDS>

                                 Figure 20

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 would also like to thank the ASDF working group
   for their excellent feedback and steering of the document.

Authors' Addresses

   Rohit Mohan
   Cisco Systems
   170 West Tasman Drive
   San Jose,  95134
   United States of America
   Email: rohitmo@cisco.com







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


   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





































Mohan, et al.            Expires 28 August 2026                [Page 27]
