]> Universität Bremen TZI

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

Applications and Real-Time ASDF WG IoT Link Web Linking This document defines and registers an sdfType "link" for the Semantic Definition Format (SDF) for Data and Interactions of Things (draft-ietf-asdf-sdf). 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 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. A common data type that occurs in the modeling of IoT devices is the link. defines the concept of Web Linking, which, apart from the target URI that any link will contain, can provide additional parameters, such as the "link relation type" that explains the relationship expressed by the link, as well as "target attributes" that provide additional information about the target of the link (without a need to "dereference", i.e., follow, the link). This document defines and registers an sdfType "link" for the Semantic Definition Format. This type models an abstract "serialization" of a link, in a way that is compatible with the way SDF maps information models to its data modeling language.

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

The sdfType "link" The sdfType "link" is intended to be used with the SDF "type" of "object". The members of that object are strings that are named the same as the link parameter (attribute) names. The special parameter name "href" is used to express the link target. (Parameter names specific to the Constrained RESTful Environment (CoRE) are also discussed in .) Note that attribute names and relation type names are case-insensitive in . Strings that are case-insensitive in MUST be in their lowercase form when used in this specification. An example for the instance of a link is provided in : ;rt="temperature-c";if="sensor", ]]> To hold a link like this, we could describe an SDF affordance that is specific on the target attributes above, but does not contain instance-specific (run-time) information on the actual URI that points to the link target. An sdfProperty for that could look like:

Discussion Links play an important role in SDF modeling both during definition time (for adding information to a model, such as in sdfRef) and during run time (for making links to instances into a subject of data and interaction modeling). The present document is an early attempt at addressing the run-time usage of links, in particular links that fit the Web Linking abstractions. A related draft addresses definition-time links, but does seem to touch modeling run-time use of links as well (e.g., by discussing "writable" link relations). Not all links used in ecosystems are based on URIs. E.g., OMA has "object links", which are basically pairs of numbers (object/instance). These ecosystem links may have some structure that should be modeled in the SDF model (e.g., where the object id part of a link always has to have a specific value). This structure can be mapped into URI strings using some convention, e.g., an OMA object link could be oma-object:3303:0 (where oma-object is placeholder for a URI scheme to be defined). However, burying structural components of the ecosystem-specific link in a string syntax makes it hard to access and control those components from the model. TODO: Examples are needed to show how the OCF collection pattern is addressed by the current specification.

Security Considerations The security considerations of apply in a general way, although modeling a link as a datatype does not incur all of the security considerations that will apply to actually interchanging these links. (TODO)

IANA Considerations // RFC Ed.: please replace RFC XXXX with this RFC number and remove this note. IANA is requested to register the sdfType "link" in the "sdfType Values" sub-registry in the "SDF Parameters" registry, with the following completion for the registration template: Registration for sdfType "link"

Name	Description	type	JSON Representation	Reference
link	A Web Link	object	object members for link attributes	RFCXXXX

References Normative References KTC Control AB Universität Bremen TZI Ericsson The Semantic Definition Format (SDF) is concerned with Things, namely physical objects that are available for interaction over a network. SDF is a format for domain experts to use in the creation and maintenance of data and interaction models that describe Things. An SDF specification describes definitions of SDF Objects/SDF Things and their associated interactions (Events, Actions, 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. 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 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] Ericsson The Semantic Definition Format (SDF) base specification defines set of basic information elements that can be used for describing a large share of the existing data models from different ecosystems. While these data models are typically very simple, such as basic sensors definitions, more complex models, and in particular bigger systems, benefit from ability to describe additional information on how different definitions relate to each other. This document specifies an extension to SDF for describing complex relationships in class level descriptions. This specification does not consider instance- specific information. The Constrained RESTful Environments (CoRE) specifications apply web technologies to constrained environments. One such important technology is Web Linking (RFC 8288), which CoRE specifications use as the basis for a number of discovery protocols, such as the Link Format (RFC 6690) in the Constrained Application Protocol's (CoAP's) resource discovery process (Section 7.2 of RFC 7252) and the Resource Directory (RD) (RFC 9176). Web Links can have target attributes, the names of which are not generally coordinated by the Web Linking specification (Section 2.2 of RFC 8288). This document introduces an IANA registry for coordinating names of target attributes when used in CoRE. It updates the "RD Parameters" IANA registry created by RFC 9176 to coordinate with this registry.

Acknowledgments Discussions in the OneDM liaison organization shaped this proposal.