]> Universität Bremen TZI

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

Ericsson

Jorvas 02420 Finland ari.keranen@ericsson.com

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: Further examples that show sdfType "link" in context are in .

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 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. 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] 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. 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. This document defines two strategies for handling long lines in width-bounded text content. One strategy, called the "single backslash" strategy, is based on the historical use of a single backslash ('\') character to indicate where line-folding has occurred, with the continuation occurring with the first character that is not a space character (' ') on the next line. The second strategy, called the "double backslash" strategy, extends the first strategy by adding a second backslash character to identify where the continuation begins and is thereby able to handle cases not supported by the first strategy. Both strategies use a self-describing header enabling automated reconstitution of the original content.

Examples sdfType "link" can be used to specify links with information specific to an organization's ecosystem. In many cases, sdfRef (see ) provides a convenient way to assemble the link specification from elements that are generic for an organization and elements that are specific to the model being defined.

Constructing a Link from an Organization's Ecosystem If the organization example.com provides a definition for an idlink that is intended to be referenced to obtain more information about the sdfObject myObj, this could look like: This example assumes example.com has exported a definition for idlink such as the following:

Using with OMA test object As a more specific example, the following assumes that openmobilealliance.org has provided a definition under objlink for the Object Links defined for LwM2M. Add reference! \".", "oma:id": 180, "sdfRef": "omatypes:corelink" } } } } } ]]> The following is a potential definition that openmobilealliance.org could export that provides sdfRef-friendly descriptions of LwM2M core links as well as the more LwM2M specific object links:

List of Tables

:

Acknowledgments Discussions in the OneDM liaison organization shaped this proposal.