]> Universität Bremen

Germany jan.romann@uni-bremen.de

Universität Bremen TZI

Postfach 330440 Bremen D-28359 Germany +49-421-218-63921 cabo@tzi.org

Applications and Real-Time ASDF IoT Link Information Model Interaction Model Data Model This document specifies instance-related messages to be used in conjunction with the Semantic Definition Format (SDF) for Data and Interactions of Things (RFC 9880). Split into four "archetypes", SDF messages are always governed by SDF models, strictly separating instance and class information. Context information plays a crucial role both for lifecycle management and actual device interaction. This revision refines the structure and terminology used with SDF messages, and further improves the alignment with the non-affordance draft and its sdfContext keyword. About This Document Status information for this document may be found at . Discussion of this document takes place on the "A Semantic Definition Format for Data and Interactions of Things" (ASDF) Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The Semantic Definition Format for Data and Interactions of Things (SDF, ) is a format for domain experts to use in the creation and maintenance of data and interaction models in the Internet of Things. SDF is an Interaction Modeling format, enabling a modeler to describe the digital interactions that a class of Things (devices) offers, including the abstract data types of messages used in these interactions. SDF is designed to be independent of specific ecosystems that specify conventions for performing these interactions, e.g., over Internet protocols or over ecosystem-specific protocol stacks. SDF does not define representation formats for the Instance Information that is exchanged in, or the subject of such, interactions; this is left to the specific ecosystems, which tend to have rather different ways to represent this information. This document discusses Instance Information in different types and roles. It defines an abstraction of this, as an eco-system independent way to reason about this information. This abstraction can be used at a conceptual level, e.g., to define models that govern the instance information. However, where this is desired, it also can be used as the basis for a concrete neutral representation (Format) that can actually be used for interchange to exchange information and parameters for interactions to be performed. In either case, the structure and semantics of this information are governed by SDF Models. This document is truly work in progress. It freely copies examples from the document that evolves in parallel, with a goal of further synchronizing the development where that hasn't been fully achieved yet. After the discussion stabilizes, we'll need to discuss how the information should be distributed into the different documents and/or how documents should be merged.

Conventions and Definitions The definitions of , , and apply. Terminology may need to be imported from .

Representation:

As defined in Section of RFC 9110 , but understood to analogously apply to other interaction styles than Representational State Transfer as well.

Instantiation:

Instantiation is a process that takes a Model, some Context Information, and possibly information from a Device and creates an Instance.

Instance:

Anything that can be interacted with based on the SDF model. E.g., the Thing itself (device), a Digital Twin, an Asset Management system... Instances are modeled as "data at rest", not "data in flight" (the latter are called "Message" and actually are/have a Representation). Instances that relate to a single Thing are bound together by some form of identity. Instances become useful if they are "situated", i.e., with a physical or digital "address" that they can be found at and made the subject of an interaction.

Message:

A Representation that is exchanged in, or is the subject of, an Interaction. Messages are "data in flight", not instance "data at rest" (the latter are called "Instance" and are modeled by the interaction model). Depending on the specific message, an abstract data model for the message may be provided by the sdfData definitions (or of declarations that look like these, such as sdfProperty) of an SDF model. Deriving an ecosystem specific representation of a message may be aided by Supplements that apply to the SDF model providing the abstract data model.

Message Archetype:

A message with specific content and effect, covering a wider set of different use cases. In this document, we are observing a total of four such archetypes: Snapshot Messages, Construction Messages, Delta Messages, and Patch Messages.

Snapshot:

A message that attempts to describe the state of an Instance at a particular moment (which may be part of the context). This state information may either be related to interaction affordances or to the Thing's context. When a Snapshot message contains affordance-related information, it may be considered a "proofshot" -- they are "proofs" in the photographic sense, i.e., they may not be of perfect quality, as inaccuracies could occur while capturing the affordance state. Conversely, Snapshot messages that (only) contain context information may be referred to as "Context Snapshots". Not all state that is characteristic of an Instance may be included in a Snapshot (e.g., information about an active action that is not embedded in an action resource). Snapshots may depend on additional context (such as the identity of the Instance and a Timestamp). An interaction affordance to obtain a Snapshot may not be provided by every Instance; instead, the affordance may be "baked into" the device and could be discoverable via a well-known URI.

Delta:

Delta messages are syntactically similar to Snapshots, but may be used to only report information that has changed compared to a given reference Snapshot or Delta message.

Construction:

Construction messages enable the creation of a digital Instance, e.g., initialization/commissioning of a device or creation of its digital twins. They are like Snapshots, in that they embody a state, however this state needs to be precise so the construction can actually happen.

Patch:

Patch messages update the otherwise immutable state of a device or its digital twin by triggering a reconfiguration or recommisioning. Similar to Delta messages, Patch messages are referring to an already existing state that is altered in accordance with the information contained within the message.

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 () () when, and only when, they appear in all capitals, as shown here.

Instance Information and SDF The instantiation of an SDF model does not directly express an instance, which is, for example, a physical device or a digital twin. Instead, the instantiation produces an instance-related SDF message, which adheres to a common message format and is always controlled by the corresponding SDF model. Depending on the recipient and its purpose, a message can be interpreted as a report regarding the state of a Thing or the instruction to change it when consumed by the recipient. Taking into account previous revisions of this document as well as , we identified two main dimensions for covering the potential use cases for SDF messages:

1. the intended effect of a message, which can either be a report or an update of a Thing's state, and
2. the actual content of the message, which may be freestanding (without a reference to a previous message or state) or relative (with such a reference).

The distinction of the intended effect between "update" or "state" is comparable to YANG's "config" statement (), a flag value indicating whether a definition represents configuration or state data. Based on these considerations (as illustrated by the systematization in ), we can identify the following four message archetypes:

1. Snapshot messages that may contain contain both affordance-related and context information, including information about a Thing's identity,
2. Construction messages that trigger a Thing's initial configuration process or its commissioning,
3. Delta messages that indicate changes that have occurred since a reference state report, and
4. Patch messages that update the Thing's state.

Systematization of messages along the dimensions "Content" and "(Intended) Effect".

		Content
		Freestanding	Relative
(Intended) Effect	State Exposure	Snapshot	Delta
	State Change	Construction	Patch

The common message format can be used for all four message archetypes. specifies the formal syntax of SDF messages that all normative statements as well as the examples in this document will adhere to. This syntax can serve to describe both the abstract structure and the concrete shape of the messages that can be used as a neutral form in interchange. In the following, we will first outline a number of general principles for SDF messages, before detailing the specific archetypes we define in this document. The specification text itself will be accompanied by examples that have been inspired by and that each correspond with one of the four archetypes.

Axioms for SDF messages SDF messages are controlled by a model (class-level information), which normally is the interaction model of the device. That interaction model may provide a model of the interaction during which the message is interchanged (at least conceptually), or it may be a "built-in" interaction (such as a Snapshot or Construction Message) that is implicitly described by the entirety of the interaction model. This may need to be augmented/composed in some way, as device modeling may be separate from e.g. asset management system modeling or digital twin modeling. SDF messages use JSON pointers into the model in order to link the information to the model. SDF messages are conceptual and will often be mapped into ecosystem-specific protocol messages (e.g., a bluetooth command). It is still useful to be able to represent them in a neutral ("red-star") format, which we build here as an adaption of the JSON-based format of the models themselves. An ecosystem might even decide to use the neutral format as its ecosystem-specific format (or as an alternative format). SDF messages may be plain messages, or they may be deltas (from a previous state) and/or patches (leading from a previous or the current state to a next state). Several media types can be defined for deltas/patches; JSON merge-patch is already in use in SDF (for sdfRef) and therefore is a likely candidate. (Assume that some of the models will be using Conflict-free replicated data types (CRDTs) to facilitate patches.)

Context Information Messages always have context, typically describing the "me" and the "you" of the interaction, the "now" and "here", allowing deictic statements such as "the temperature here" or "my current draw". Messages may have to be complemented by this context for interpretation, i.e., the context needed may need to be reified in the message (compare the use of SenML "n"). Information that enables interactions via application-layer protocols (such as an IP address) can also be considered context information. For this purpose, we are using the sdfContext keyword introduced by . TODO: explain how could be used to obtain device names (using urn:dev:org in the example). Note that one interesting piece of context information is the model itself, including the information block and the default namespace. This is of course not about the device or its twin (or even its asset management), because models and devices may want to associate freely. Also note that multiple models may apply to the same device (including but not only revisions of the same models).

Message Format The data model of SDF messages makes use of the structural features of SDF models (e.g., when it comes to metadata and namespace information), but is also different in crucial aspects.

Information Block The information block contains the same qualities as an SDF model and, additionally, a mandatory messageId to uniquely identify the message. Furthermore, Delta messages can utilize the previousMessageId in order to link two messages and indicate the state change. Qualities of the Information Block

Quality	Type	Description
title	string	A short summary to be displayed in search results, etc.
description	string	Long-form text description (no constraints)
version	string	The incremental version of the definition
modified	string	Time of the latest modification
copyright	string	Link to text or embedded text containing a copyright notice
license	string	Link to text or embedded text containing license terms
messageId	string	Unique identifier of this SDF message
previousMessageId	string	Identifier used to connect this SDF message to a previous one
timestamp	string	Indicates the point in time this SDF message refers to
features	array of strings	List of extension features used
$comment	string	Source code comments only, no semantics

Namespaces Block Similar to SDF models, SDF messages contain a namespaces block with a namespace map and the defaultNamespace setting. In constrast to models, including a namespace quality is mandatory as at least one namespace reference is needed to be able to refer to the SDF model the message corresponds with. Namespaces Block

Quality	Type	Description
namespace	map	Defines short names mapped to namespace URIs, to be used as identifier prefixes
defaultNamespace	string	Identifies one of the prefixes in the namespace map to be used as a default in resolving identifiers

Instance-of Block Distinct from SDF models are two instance-specific blocks, the first of which is identified via the sdfInstanceOf keyword. Via the model keyword, this quality defines the sdfObject or sdfThing the sdfInstance quality from the next section is referring to. The version, minVersion, maxVersion, exclusiveMinVersion, amd exclusiveMaxVersion qualities optionally allow for specifying a version or version range of the model. Furthermore, via the patchMethod field, a patch algorithm different from JSON Merge Patch can be specified. Instance-of Block

Quality	Type	Description
model	string	Defines the entry point for sdfInstance by pointing to an sdfObject or an sdfThing. Always refers to the target namespace indicated by the defaultNamespaceand namespaces qualities.
version	string	The exact version the model this message is referring to.
minVersion	string	The (inclusive) minimal version of the model this message is referring to.
maxVersion	string	The (inclusive) maximal version of the model this message is referring to.
exclusiveMinVersion	string	The exclusive minimal version of the model this message is referring to.
exclusiveMaxVersion	string	The exclusive maximal version of the model this message is referring to.
patchMethod	string	Allows for overriding the default patch method (JSON Merge Patch) by providing a registered value.
$comment	string	Source code comments only, no semantics

Instance Block In the instance block, state information for properties, actions, and events as well as context information can be included. Depending on the archetype, this information will either be used to report a Thing's current state, to report state changes, or to update state via a patch or reconfiguration. In addition to the messageId and previousMessageId from the info block, we are able to refer to

• the point in time when the information regarding the device state has been captured (via the timestamp quality) and
• the device identity (via the thingId qualitity in the sdfInstance block).

The SDF message has to follow the structure of the definition that is indicated by the model entry point (although, depending on the archetype, information that has not changed or will not be updated can be left out.) The alternating structure of the SDF model (e. g., sdfObject/envSensor/sdfProperty/temperature) is repeated within the message, with the top-level sdfObject or sdfThing being replaced by sdfInstance at the entry point. Note that we also have to replicate a nested structure via sdfThing and/or sdfObject if present in the referenced SDF model. Instance Block

Quality	Type	Description
thingId	string	(Optional) identifier of the instance (e.g., a UUID)
sdfThing	map	Values for the thing entries in the referenced SDF definition
sdfObject	map	Values for the object entries in the referenced SDF definition
sdfContext	map	Values for the context entries in the referenced SDF definition
sdfProperty	map	Values for the properties in the referenced SDF definition
sdfAction	map	Values for the actions in the referenced SDF definition
sdfEvent	map	Values for the events in the referenced SDF definition

Message Archetypes Based on the common message format defined in and the systematization from , we can derive a set of four archetypes that serve different use cases and recipients.

Snapshot Messages This message contains information on a Thing's state, both in terms of context information and the state of individual affordances. In the message, the previousMessageId field in the information block MUST NOT be present. Furthermore, when transmitting this message in its JSON format, the content type application/sdf-snapshot+json MUST be indicated if supported by the protocol used for transmission. Snapshot messages MAY only contain values for a subset of all possible affordances and context information exposed by a Thing. Security-related aspects, e.g. regarding authentication and authorization, MUST be taken into account when issueing a state report for a requesting party. In practical use, we can at least differentiate two use cases for snapshot messages. The corresponding message variants are (colloquially) referred to as "Context Snapshots" and "Proofshots". Context Snapshots only contain context information related to a Thing (indicated via the sdfContext quality). gives an example for this kind of message.

Example of an SDF context snapshot.

Proofshot Messages are supersets of context snapshots that may also include state information associated with a Thing's interaction affordances(properties, actions, and events). Note that while the format for describing the state of properties is clearly governed by the schema information from the corresponding sdfProperty definition, it is still unclear how to best model the state of sdfActions and sdfEvents. shows a proofshot that captures the state of a sensor. Here, every property and context definition of the corresponding SDF model (see ) is mapped to a concrete value that satisfies the associated schema.

SDF proofshot example.

Construction Messages Construction messages are structurally equivalent to snapshot messages but may only contain context information. Furthermore, the recipient of a construction message is supposed to initiate a configuration or comissioning process upon recption. Construction messages MUST be indicated by the media type application/sfd-construction+json if possible. A construction message for a temperature sensor might assign an identity and/or complement it by temporary identity information (e.g., an IP address); its processing might also generate construction output (e.g., a public key or an IP address if those are generated on device) which can be described via Snapshot or Delta messages. The creation of Construction messages is linked to the invocation of a constructor that starts the actual construction process. In practice, these constructors are going to be modeled as an sdfAction, although the way the sdfAction is going to be used exactly is not entirely clear yet. Note that it is not quite clear what a destructor would be for a physical instance -- apart from a scrap metal press, but according to RFC 8576 we would want to move a system to a re-usable initial state, which is pretty much a constructor. shows a potential SDF construction message that initializes a device, setting its manufacturer and firmwareVersion as context information. The construction message also assigns a thingId, the unit of reported temperature values, and an initial ipAddress that can be used with the interaction affordances that may be present in the corresponding SDF model.

Example for an SDF construction message

A special type of construction message that only contains identity-related information may be called an Identity Manifest. shows an example of an identity manifest that is structurally identical to the construction message from , with the non-identity-related information left out. Via sdfRequired, an SDF model can indicate which context information must be present and therefore initialized within an instance. All definitions included in sdfRequired MUST also be present in a construction message, while definitions could be left out.

Example of an SDF identity manifest

Delta Messages Delta messages describe updates to a Thing's state relative to a previous message. For this purpose, a previousMessageId MUST be present in the info block. When transmitting delta messages, the media type application/sdf-delta+json MUST be used if possible. By default, the values contained in the message are applied to the preceding message(s) via the JSON Merge Patch algorithm. Via the patchMethod quality, different patch algorithms MAY be indicated. shows an example Delta message that reports state changes compared to the ones reported in the previous message (identified via its previousMessageId). In this example, only the temperature that has been measured by the sensor has changed, which is why it is the only piece of information that is included. Delta messages could be used in the Series Transfer Pattern , which may be one way to model a telemetry stream from a device.

Example of an SDF message that serves as a delta.

Patch Messages Patch messages are structurally equivalent to delta messages, but once again are only allowed to contain context information. They utilize a patch mechanism (which may be explicitly indicated via the patchMethod quality) to alter the state of a Thing instead of reporting state changes. Since patch messages are not referring to a preceding message, a previosMessageId MUST NOT be present in the information block. When transmitting state patches, the media type application/sdf-patch+json MUST be used if possible. An example Patch Message is shown in , where a change of the device's mountType is signalled.

Example of an SDF context patch message that uses the common message format.

Practical uses for patch message include digital twins , where changes to physical attributes (such as the location) need to be reflected in the digital representation of a Thing.

Application Scenarios The common message format and the four archetypes are usable in a number of use cases, some of which we are going to specify in the following. Other specifications may define additional use cases SDF messages can be used for.

Construction In SDF models, we can treat a Thing's sdfProperty definitions as construction parameters. Construction messages can serve as an ecosystem-independent way for initializing properties, especially those that are specified as non-writable. shows an example for an SDF model where the ipAddress and deviceIdentity are supposed to be initialized at construction time, since they are required and not writable via regular interactions during runtime. As the unit property has a default value (Cel for degrees Celcius), it does not have to be initialized during construction. However, for all of these properties, a reconfiguration during runtime is possible. In this example, the deviceIdentity would be retrievable like a "regular", but immutable property affordance. While the ipAddress might be used for interaction affordances (e.g., by other models that build upon this one), the temperature property is "importing" the value of the unit property via a new quality called sdfParameters, where pairs of quality names and JSON pointers are used to import values from sdfProperty definitions. shows an example for an SDF model where the ipAddress and deviceIdentity are supposed to be initialized at construction time, since they are modeled as mandatory (via sdfRequired) sdfContext definitions, making them non-writable via "regular" interactions during runtime. As the unit property has a default value (Cel for degrees Celcius), it does not have to be initialized during construction. However, for all of these context definitions, a reconfiguration during runtime is possible. While the ipAddress might be used for interaction affordances (e.g., by other models that build upon this one), the temperature property is "importing" the value of the unit property via a new quality called sdfParameters, where pairs of quality names and JSON pointers are used to import values from sdfContext definitions.

Example for SDF model with constructors

Based on the SDF model above, a Construction Message such as the one shown in can trigger the construction process. As indicated via sdfRequired, this process must involve the initialization of the device's identity definitions and IP address.

Protocol Binding Information When using the sdfProtocolMap concept introduced in , some protocols may need context information such as a hostname or an IP address to actually be usable for interactions. This corresponds with the fact that the parameters related to application-layer protocols are often class-level information and therefore not necessarily instance-specific. For example, all instances of a smart light may use similar CoAP resources, with the only difference being the concrete IP address assigned to them. Therefore, we can utilize context information that varies between instances to complement the model information provided via an sdfProtocolMap. illustrates the potential relationship between the two concepts in an SDF model. Here, a (hypothetical) CoAP protocol mapping specification defines an interface for parameters such as an IP address. Via JSON pointers, the sdfParameters within the sdfProtocolMap are linked to compatible sdfProperty definitions that may further restrict the set of allowed values via their schema.

Example of an SDF model where a CoAP-based protocol map points to the definition of relevant context information: an IP address.

shows how a Snapshot Message can report the necessary IP address that is needed for retrieving the temperature value from the sensor described by the SDF model above.

Example of a snapshot message that provides the IP address needed to perform a CoAP-based interaction with the sensor from the previous figure.

Modelling the State of Interaction Affordances Snapshot and (in a relative fashion) Delta Messages can report the current state associated with interaction affordances. For sdfProperty (and sdfContext) definitions, this is very straightforward, as previously seen in in . Actions and events, however, need to be handled differently: In the case of actions, the state of one or more actions is reported, which might already be in a completed or error state, or may also still be running. For events, a history is reported that includes the returned values. The exact of number of action and event reports is implementation-dependent and may vary between deployments. Models that add additional sdfProtocolMap definitions may also define protocol-specific ways to control the size of the histories returned. shows an example of a Snapshot Message for a lightswitch which reports the results of two toggle actions, one of which failed. The successfully completed action caused the emission of a toggleEvent with the same timestamp. As the lightswitch was turned on, the event was emitted with a value of true.

Example of an SDF Snapshot Messages that reports an action and an event history.

Model and Message Conversion SDF messages increase the semantic capabilities of SDF, which means that it can cover more ecosystem-specific concepts when used as a conversion input or output. This allows us to better cover description formats that use instance-related information in their data models, but poses a challenge when the distinction from model-related information is not clearly drawn. shows an initial example from the Web of Things (WoT) ecosystem that uses a CoAP Protocol Binding in its property affordance status. Analyzing this model, we can quickly see that most of the information contained is actually model-related information that could apply to other lamps as well. This includes the schema information for the status, the security mode (or lack thereof) as well as the protocol binding information. Important exceptions are the hostname or (in this case) the IP address of the Thing, its id as well as its title that are specific to this device.

WoT TD example showcasing a mix of model and instance information.

illustrates how an SDF model can cover the model-related information from the WoT TD example. Note that this example contains a separate ipAddress property that is used for this piece of context information that serves as a paramter for resolved CoAP URL.

SDF model containing the model-related information from the previous WoT example.

in turn shows an SDF message that contains only the instance-related information from the WoT TD example. Besides the contextual ipAddress, this includes also the current value of the status property. The id that was part of the WoT TD has been mapped to the thingId quality under sdfInstance. The instance-specific title has no real equivalent in SDF messages yet, but it could be added to sdfInstance in future revisions.

SDF message containing the instance-related information from the previous WoT example.

While these examples highlight the potential of SDF messages for a clean separation of model and instance information, they also raise a number of questions, for example about the role of namespaces for SDF conversion results and the location where the resulting SDF models may be stored to potentially make them accessible to consumers. In practice, these questions may not be as relevant when converting from SDF to (in this case) WoT or when using SDF only as an internal translation medium for bridging between two ecosystems. However, these considerations emphasize the need for a set of standardized, reusable building blocks that can also be used for model and message conversion.

Discussion SDF messages close an important semantic gap of SDF, which so far was only capable of describing device classes and not instances. There are, however, a few aspects that need special consideration and have to be addressed by more fine-grained specifications in the future that will buid upon this one. SDF messages allow for noting down timestamps that currently relate to the message as a whole. Since the values contained within an SDF message might reflect state updates such as measurements that occurred before composing the message, this timestamp cannot accurately reflect the device state at that exact moment. In this sense, SDF messages really are imperfect "proofshots" when it comes to the state of affordances, also considering that there might be concurrency problems if a device is updated while generating a Snapshot or Delta message. With IoT devices, many additional potential time-related problems arise, as devices might have access to (credible) time information or can only measure time unreliably due to resource constraints, accuracy problems, and/or their sleeping behavior (). In cases like these, timestamps might have to be omitted from SDF messages or need to be estimated by a more reliable intermediary. Discuss expressing a device's "purpose of life" via context information Discuss using context information to indicate provence

Security Considerations The security considerations of apply to this document as well. Entities processing SDF messages need to take measures to ensure the provenance of SDF messages, including authenticity and integrity. For this purpose, they may use the context and state information contained within a given message. Instance-related information may might only be available in certain scopes, e.g. when it comes to security-related configuration parameters. This information MUST NOT be exposed to unauthorized entities and therefore MUST be excluded from SDF messages. Deployments MAY rely on an authorization framework such as ACE-OAuth to limit the included information or access to messages as a whole to a certain scope.

IANA Considerations TODO: Add media type registrations

References Normative References The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, and Properties), as well as the Data types for the information exchanged in those interactions. Tools convert this format to database formats and other serializations as needed. This specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the serialisation of such links in HTTP headers with the Link header field. The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes. This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230. Electronics and Telecommunications Research Institute Electronics and Telecommunications Research Institute This document describes an extension to the Semantic Definition Format (SDF) for representing non-affordance information of Things, such as physical, contextual, and descriptive metadata. This extension introduces a new Class Name Keyword, sdfContext, that enables comprehensive modeling of Things and improves semantic clarity. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References University of California, Irvine This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server. [STANDARDS-TRACK] This specification defines the JSON merge patch format and processing rules. The merge patch format is primarily intended for use with the HTTP PATCH method as a means of describing a set of modifications to a target resource's content. Universität Bremen TZI Universität Bremen The Semantic Definition Format (SDF) is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things, i.e., physical objects that are available for interaction over a network. It was created as a common language for use in the development of the One Data Model liaison organization (OneDM) models. Tools convert this format to database formats and other serializations as needed. An SDF specification often needs to be augmented by additional information that is specific to its use in a particular ecosystem or application. SDF Supplements provide a mechanism to represent this augmentation. Universität Bremen TZI Ericsson Universitat Politecnica de Catalunya The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in research and standardization work for constrained-node networks. This document obsoletes RFC 7228. When devices are deployed in locations with no real-time access to the Internet, obtaining a trusted time for validation of time limited tokens and certificates is sometimes not possible. This document explores the options for deployments in which the trade-off between availability and security needs to be made in favor of availability. While considerations are general, terminology and examples primarily focus on the ACE framework. Electronics and Telecommunications Research Institute Electronics and Telecommunications Research Institute This memo specifies SDF modeling for digital twins, i.e., digital twin systems, and their things. An SDF is a format that is used to create and maintain data and interaction, and to represent the various kinds of data that is exchanged for these interactions. The SDF format can be used to model the characteristics, behavior and interactions of things, i.e. physical objects, in digital twins that contain things as components. WISHI Wiki Universität Bremen TZI Ericsson Many applications make use of Series of data items, i.e., an array of data items where new items can be added over time. Where such Series are to be made available using REST protocols such as CoAP or HTTP, the Series has to be mapped into a structure of one or more resources and a protocol for a client to obtain the Series and to learn about new items. Various protocols have been standardized that make Series-shaped data available, with rather different properties and objectives. The present document is an attempt to extract a common underlying pattern and to define media types and an access scheme that can be used right away for further protocols that provide Series-shaped data. This document describes a new Uniform Resource Name (URN) namespace for hardware device identifiers. A general representation of device identity can be useful in many applications, such as in sensor data streams and storage or in equipment inventories. A URN-based representation can be passed along in applications that need the information. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE-OAuth. The framework is based on a set of building blocks including OAuth 2.0 and the Constrained Application Protocol (CoAP), thus transforming a well-known and widely used authorization solution into a form suitable for IoT devices. Existing specifications are used where possible, but extensions are added and profiles are defined to better serve the IoT use cases. Cisco Systems Cisco Systems Ericsson 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 a specific protocol. This document defines protocol mappings for Bluetooth Low Energy and Zigbee, and the mechanism can be extended to other protocols such as HTTP and CoAP. This document also describes a method to extend SCIM with an SDF model mapping.

Example SDF Model shows the model all of the examples for SDF messages are pointing to in this document. Note how the namespace is managed here to export the envSensor component into sensors:#/sdfObject/envSensor, which is the "entry point" used in the instance messages within the main document.

SDF Model that serves as a reference point for the SDF messages in this draft

Formal Syntax of SDF Messages ? defaultNamespace: text ? sdfInstanceOf: sdf-instance-of ? sdfInstance: sdf-instance } sdfinfo = { ? title: text ? description: text ? version: text ? copyright: text ? license: text ? messageId: text ; Identifier used to connect this instance message to a previous ; one: ; Allows this instance message to only contain values that have ; actually changed, turning it into a "Delta" or a "Patch", ; depending on the purpose of the message. ? previousMessageId: text ? timestamp: modified-date-time ? modified: modified-date-time ? features: [ ] optional-comment } sdf-instance-of = { model: text ? patchMethod: text ; default is merge-patch optional-comment } optional-comment = ( ? $comment: text ; source code comments only, no semantics ) ; Shortcut for a map that gives names to instances of X ; (has keys of type text and values of type X) named = { * text => X } commonqualities = ( optional-comment ) ; For describing the state of instances at a given point in time ; ; An sdfInstance can refer to either an sdfThing or an sdfObject. ; Structurally, it is mostly equivalent to that of an sdfThing ; with the additiona of a thingId quality. sdf-instance = ( ? thingId: text thingqualities ) objectqualities = { commonqualities cpaedataqualities } thingqualities = { sdfThing: named sdfObject: named commonqualities cpaedataqualities } cpaedataqualities = ( ? sdfContext: named ; Models the current state of the instance's properties ? sdfProperty: named ; Models the current state of the instance's action affordances ; ; DISCUSS: How should the state of actions be modeled? ? sdfAction: named ; Models an history for every event affordance ? sdfEvent: named ) eventhistory = [* eventqualities] eventqualities = { outputValue: allowed-types timestamp: modified-date-time } allowed-types = number / text / bool / null / [* number] / [* text] / [* bool] / {* text => any} modified-date-time = text .abnf modified-dt-abnf modified-dt-abnf = "modified-dt" .det rfc3339z ; RFC 3339 sans time-numoffset, slightly condensed rfc3339z = ' date-fullyear = 4DIGIT date-month = 2DIGIT ; 01-12 date-mday = 2DIGIT ; 01-28, 01-29, 01-30, 01-31 based on ; month/year time-hour = 2DIGIT ; 00-23 time-minute = 2DIGIT ; 00-59 time-second = 2DIGIT ; 00-58, 00-59, 00-60 based on leap sec ; rules time-secfrac = "." 1*DIGIT DIGIT = %x30-39 ; 0-9 partial-time = time-hour ":" time-minute ":" time-second [time-secfrac] full-date = date-fullyear "-" date-month "-" date-mday modified-dt = full-date ["T" partial-time "Z"] ' ]]>

List of Figures

:

:

:

:

:

:

:

:

:

:

:

:

:

:

List of Tables

:

:

:

:

:

Acknowledgments (TODO)