| Internet-Draft | SDF Protocol Mapping for CoAP | March 2026 |
| Romann | Expires 11 September 2026 | [Page] |
This memo defines vocabulary to integrate the Constrained Application Protocol (CoAP) into Protocol Mappings [I-D.ietf-asdf-sdf-protocol-mapping] for the Semantic Definition Format (SDF) for Data and Interactions of Things [RFC9880].¶
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-romann-asdf-coap-protocol-map/.¶
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/JKRhb/sdf-coap-protocol-map.¶
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 11 September 2026.¶
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.¶
This memo defines vocabulary to integrate the Constrained Application Protocol (CoAP) [RFC7252] into Protocol Mappings [I-D.ietf-asdf-sdf-protocol-mapping] for the Semantic Definition Format (SDF) for Data and Interactions of Things [RFC9880].¶
The vocabulary and "feature-based" approach taken within this document is heavily inspired by the CoAP Protocol Binding [WoT-CoAP-Binding] for the W3C Web of Things (WoT), which is to be used with WoT Thing Descriptions (TDs). Considering SDF's role as a "hub format", we aspire to be able to also take into account CoAP vocabulary when converting from and to TDs.¶
An important additional aspect to the base protocol-mapping specification [I-D.ietf-asdf-sdf-protocol-mapping] is the fact that we rely on instance-related messages [I-D.ietf-asdf-instance-information] to complement protocol information present in SDF models. Compared to the WoT approach, we achieve a stricter separation of model and instance information this way, reducing the amount of information that needs to be supplied by a Thing itself to a minimum to enable interactions.¶
The definitions of [RFC9880], [I-D.ietf-asdf-sdf-protocol-mapping], and [I-D.ietf-asdf-instance-information] apply.¶
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.¶
The Constrained Application Protocol (CoAP) has been originally specified in [RFC7252], but has since been extended with a number of specifications such as blockwise transfer [RFC7959], the observation of resources [RFC7641], and additional transport mechanisms [RFC8323] in addition to UDP and DTLS. The blockwise transfer and Observe extensions in particular are essential for using CoAP in practice, which is why covering the only the base specification in this document would not not enough.¶
A protocol mapping for CoAP should support the features currently defined for CoAP, but it should also be extensible to cover potential future additions to the CoAP specification body as well.¶
CoAP can be used with all three kinds of interaction affordances defined in SDF [RFC9880], namely, sdfProperty, sdfAction, and sdfEvent.
The protocol mapping for an affordance MUST specify the method as well as an href, which combines the URI path and potential query parameters for the resource the interaction affordance is mapped to.
The href quality supports URI templates [RFC6570] whose variables can be associated with data qualities via the sdfVariables map.
To differentiate between the available transport protocols, a URI scheme (with a default value of coap for CoAP over TCP) MAY be supplied.¶
Other general qualities for CoAP include parameters for blockwise transfer, the available and accepted Content-Formats, as well as the minimal polling interval that is accepted by the respective CoAP server. Note that since CoAP messages do not allow for the use of generic headers as HTTP does, all of these qualities map to standardized CoAP options with specific semantics that are registered with IANA. For this reason, we also need to explicitly cover relevant features with our protocol mapping specification.¶
In contrast to the WoT approach, the protocol binding information that is supplied via this document is targeting the model level.
That means that information such as URI paths will be shared by all device instances that adhere to the given model.
Instance-specific information, e.g., a device's host name or its ipAddress, is provided via instance-related messages [I-D.ietf-asdf-instance-information] that pass the values for the sdfParameters the protocol mapping defines via designated properties.
The selected sdfProperty definitions are indicated via JSON pointers within the sdfParameters map.¶
Per interaction affordance type, the CoAP Protocol Mapping defines at least one type of operation (read, write, invoke, and subscribe).
Currently, the definitions for these different operations look almost identitical, with the main difference being the default method per operation.
Future specifications may extend the set of operations per interaction affordance type.¶
With sdfProperty, a read operation (default method: GET) and a write operation (default method: PUT) are supported when using CoAP.¶
Note that this memo does not define an "observe" operation as it is already covered by the read operation:
With a property that is marked as observable, a client can simply include the CoAP Observe option [RFC7641] in its GET or FETCH request.
If the server that receives the request does not support the Observe option, the client can simply fall back to polling.¶
In the case sdfAction, an invoke operation is supported when using CoAP.
This operation uses the POST method by default.¶
In the case of sdfEvent, a subscribe operation is supported when using CoAP.¶
This operation is very similar to the read operation, with the main difference that a client SHOULD always assume that the indicated resource is observable.
If the observe option is not supported, the client SHOULD fall back to polling.
While polling, a client is likely to receive responses only asynchronously (i.e., when the described event actually occurs).¶
The security considerations of [RFC9880] as well as [RFC7252] apply to this document as well.¶
IANA is requested to add the following entry to the "SDF Protocol Mapping" registry.¶
| Protocol map | Protocol Name | Description | Reference |
|---|---|---|---|
| coap | Constrained Application Protocol (CoAP) | Protocol mapping for CoAP devices | This document |
This normative appendix describes the syntax of this protocol mapping definition using CDDL [RFC8610].¶
Via the defined extension points, future specifications may add new definitions to the CDDL schema.¶
same-document-pointer = text .regexp "[^:#]*"
$$SDF-PROPERTY-PROTOCOL-MAP //= (
coap: coap-property-map
)
$$SDF-EVENT-PROTOCOL-MAP //= (
coap: coap-event-map
)
$$SDF-ACTION-PROTOCOL-MAP //= (
coap: coap-action-map
)
coap-parameters = {
? host: same-document-pointer
? ipAddress: same-document-pointer
}
common-coap-definitions = (
sdfParameters: coap-parameters
sdfVariables: named<same-document-pointer>
)
; Shortcut for a map that gives names to instances of X
; (has keys of type text and values of type X)
named<X> = { * text => X }
coap-vocabulary = {
scheme: "coap" / "coaps" / "coap+tcp" / "coaps+tcp" / "coap+ws" / "coaps+ws"
method: "GET" / "POST" / "PUT" / "DELETE" / "FETCH" / "PATCH" / "iPATCH" ; TODO: Can we make this list extendable?
href: text
; An affordance can support multiple Content-Formats as input/output
? contentFormat: [ * uint ]
? accept: [ * uint ]
? minPollingInterval: uint
? blockwise: blockwise-parameters
? qblockwise: blockwise-parameters
}
blockwise-parameters = {
? block1Size: 16 / 32 / 64 / 128 / 256 / 512 / 1024
? block2Size: 16 / 32 / 64 / 128 / 256 / 512 / 1024
}
coap-property-map = {
common-coap-definitions
sdfOperations: coap-property-operations
}
coap-action-map = {
common-coap-definitions
sdfOperations: coap-action-operations
}
coap-event-map = {
common-coap-definitions
sdfOperations: coap-event-operations
}
; TODO: Add extension points
coap-property-operations = {
read: coap-vocabulary ; Also covers observe via the Observe option
write: coap-vocabulary
}
coap-action-operations = {
invoke: coap-vocabulary
}
coap-event-operations = {
subscribe: coap-vocabulary
}
¶
TODO acknowledge.¶