Thing-to-Thing Research Group K. Hartke Internet-Draft Ericsson Intended status: Experimental November 4, 2019 Expires: May 7, 2020 Resource Discovery in Constrained RESTful Environments (CoRE) using the Constrained RESTful Application Language (CoRAL) draft-hartke-t2trg-coral-reef-03 Abstract This document explores how the Constrained RESTful Application Language (CoRAL) might be used for two use cases in Constrained RESTful Environments (CoRE): CoRE Resource Discovery, which allows a client to discover the resources of a server given a host name or IP address, and CoRE Resource Directory, which provides a directory of resources on many servers. 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/. 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 May 7, 2020. Copyright Notice Copyright (c) 2019 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 Simplified BSD License text as described in Section 4.e of Hartke Expires May 7, 2020 [Page 1]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 4 2.2. Resource Directory . . . . . . . . . . . . . . . . . . . 5 2.3. Notational Conventions . . . . . . . . . . . . . . . . . 7 3. Resource Metadata . . . . . . . . . . . . . . . . . . . . . . 7 4. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 8 4.1. Well-known Resource . . . . . . . . . . . . . . . . . . . 9 4.1.1. Resource List Representation . . . . . . . . . . . . 9 4.2. Interactions . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. Getting All Resources . . . . . . . . . . . . . . . . 10 4.2.2. Getting Resources By Resource Type . . . . . . . . . 11 4.2.3. Getting Resources By Interface Type . . . . . . . . . 12 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 13 5.1. Resource Lookups . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Filter Query Representation . . . . . . . . . . . . . 13 5.2. Resource Registrations . . . . . . . . . . . . . . . . . 13 5.2.1. Registration Unit Representation . . . . . . . . . . 13 5.2.2. Registration Unit List Representation . . . . . . . . 14 5.3. Interactions . . . . . . . . . . . . . . . . . . . . . . 15 5.3.1. Getting All Resources . . . . . . . . . . . . . . . . 15 5.3.2. Getting Resources By Resource Type . . . . . . . . . 16 5.3.3. Getting Resources By Interface Type . . . . . . . . . 17 5.3.4. Getting Resources By Resource Metadata . . . . . . . 18 5.3.5. Getting All Registration Units . . . . . . . . . . . 19 5.3.6. Creating a Registration Unit . . . . . . . . . . . . 20 5.3.7. Reading a Registration Unit . . . . . . . . . . . . . 21 5.3.8. Updating a Registration Unit . . . . . . . . . . . . 22 5.3.9. Deleting a Registration Unit . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 24 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 7.1. CoRE Dictionary . . . . . . . . . . . . . . . . . . . . . 24 7.2. CoAP Content Format . . . . . . . . . . . . . . . . . . . 26 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Normative References . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . 27 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 28 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 28 Hartke Expires May 7, 2020 [Page 2]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 1. Preamble This document explores how CoRE Resource Discovery [RFC6690] and CoRE Resource Directory [I-D.ietf-core-resource-directory] might look like if based on CoRAL [I-D.ietf-core-coral]. The exploration is done in the style of a self-contained specification rather than a description of changes. This document doesn't represent a proposal or recommendation for standardization at its current stage. 2. Introduction Constrained RESTful Environments (CoRE) realize the Representational State Transfer (REST) architectural style [REST] in a suitable form for constrained nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and constrained networks [RFC7228]. CoRE technologies like the Constrained Application Protocol (CoAP) [RFC7252] are aimed at machine-to-machine (M2M) applications like smart energy and building automation. The discovery of resources hosted by a constrained server is very important in machine-to-machine applications where no humans are in the loop and static interfaces result in fragility. In the Web, the discovery of resources provided by a Web server is typically based on links in representations of resources pointing at other resources, with search engines providing an entry point to find resources based on queries. This document applies the idea of using Web Linking [RFC8288] for discovery to Constrained RESTful Environments. The discovery of resources hosted by a constrained Web server, resource metadata, and related resources is called "CoRE Resource Discovery". The main function of CoRE Resource Discovery is to provide Uniform Resource Identifiers (URIs) [RFC3986] for the resources hosted by a server, complemented by metadata about those resources and possibly links to further resources. In this document, this information is conveyed in the Constrained RESTful Application Language (CoRAL) [I-D.ietf-core-coral]. This document specifies the use of CoRAL in two use cases: Resource Discovery Allows a client to discover the resources of a server, given a server's host name or IP address. Hartke Expires May 7, 2020 [Page 3]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 Resource Directory Allows a client to discover the resources of several servers, given a resource directory's URL. Allows a server (or a third party acting on behalf of a server) to register its resources with a resource directory, given a resource directory's URL. 2.1. Resource Discovery In many M2M applications, such as home or building automation, there is a need for local clients and servers to find and interact with each other without human intervention. CoRE Resource Discovery can be used by clients in such environments to discover the resources hosted by the server given a host name or IP address. In this specification, the discovery is performed by retrieving a CoRAL representation of a well-known resource on the server, called "/.well-known/core". The representation contains a list of links to the resources of interest on the server, which are typically entry points to the different applications hosted by the server. The link targets may be annotated with resource metadata. A client would then find an appropriate resource based on the metadata. Queries based on metadata may also be specified in the query string to filter the result set. The following example shows a client discovering the resources of a CoAP server by making a GET request to the "/.well-known/core" resource. The client gets a 2.05 (Content) response with a list of links of type <http://coreapps.org/reef#rd-item> to the resources on the server. The links themselves contain metadata about the resources (such as resource type, interface description, available content formats, or even further links to other related resources). => 0.01 GET Uri-Path: .well-known Uri-Path: core Accept: TBD3 Hartke Expires May 7, 2020 [Page 4]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using base = <http://coreapps.org/base#> #using iana = <http://www.iana.org/assignments/relation/> rd-item </sensors> { ct 40 base:title "Sensor Index" } rd-item </sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } rd-item </sensors/light> { rt "light-lux" if "sensor" } The example contains links to three resources of interest on the server: </sensors>, </sensors/temp>, and </sensors/light>. For </sensors>, a content format hint ("ct") and a title ("title") are provided as resource metadata. For both </sensors/temp> and </sensors/light>, a resource type ("rt") and an interface description ("if") are provided. Additionally, two links are provided with further detail on </sensors/temp>: one to a schema describing this resource ("describedby") and one to an substitute ("alternate"). Common resource metadata are specified in Section 3. The "/.well- known/core" resource and its interface are specified in Section 4. 2.2. Resource Directory In many deployment scenarios, such as in constrained networks with sleeping servers or in large M2M deployments with bandwidth limited access networks, it is beneficial to deploy resource directory entities that store links to resources stored on other servers. A resource directory can be thought of as a limited search engine for M2M resources. In this specification, a resource directory provides the same lookup interface as a "/.well-known/core" resource, except that it provides links to resources on potentially many, many different servers. Whereas a "/.well-known/core" resource is populated by the hosting server, the resource directory provides a registration interface that Hartke Expires May 7, 2020 [Page 5]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 allows any server (or third party acting on behalf of a server) to register its resources. The registration interface is a collection resource with the common operations of create, read, update, and delete. The items of the collection are groups of links of type <http://coreapps.org/reef#rd- item> that are to be made available in the lookup interface. The following example shows a client registering a group of links with a resource directory by making a POST request to the collection resource. The client receives a 2.01 (Created) response with the location of the created collection item. The client can later use this location to update or delete the whole group of links at once. => 0.02 POST Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Content-Format: TBD3 #using <http://coreapps.org/reef#> #base <coap://[2001:db8:3::124]/> rd-item </light/left> { rt "light-lux" ct 0 } rd-item </light/middle> { rt "light-lux" ct 0 } rd-item </light/right> { rt "light-lux" ct 0 } <= 2.01 Created Location-Path: path Location-Path: to Location-Path: resource Location-Path: directory Location-Path: registrations Location-Path: 42 The following example shows a client performing a lookup on the resource directory by making a GET request to the resource directory resource. The client receives a 2.05 (Content) response with a combined view of all groups of links registered earlier, filtered by a query. Hartke Expires May 7, 2020 [Page 6]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: lookup Uri-Query: rt=light-lux Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #base <coap://[2001:db8:1::9]/> rd-item </1234> { rt "light-lux" } #base <coap://[2001:db8:3::124]/> rd-item </light/left> { rt "light-lux" ct 0 } rd-item </light/middle> { rt "light-lux" ct 0 } rd-item </light/right> { rt "light-lux" ct 0 } The resource directory and its lookup and registration interface are specified in Section 5. 2.3. Notational Conventions 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. Resource Metadata Both "/.well-known/core" resources and resource directories link to resources of interest using the <http://coreapps.org/reef#rd-item> link relation type. Metadata for these resources can be expressed by nesting the metadata inside these links. In particular, resource metadata takes the shape of nested links that either directly specify a literal value (such as a string or number) or target a related resource identified by a URI; see Section 2.3 of [I-D.ietf-core-coral] for details. The following link relation types for expressing resource metadata are defined: Hartke Expires May 7, 2020 [Page 7]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 <http://coreapps.org/base#language> The link target is a hint indicating what the (human-spoken) language of the result of dereferencing the link context should be. <http://coreapps.org/reef#media> The link target indicates the intended destination medium or media for style information for the link context. <http://coreapps.org/base#title> The link target is a label that it can be used as a human-readable identifier for the link context. Multiple labels can be specified, each as a link with the label as link target. Each link can have a nested link indicating a language tag for the label. <http://coreapps.org/coap#type> The link target is a hint indicating what the content format of the result of dereferencing the link context should be. <http://coreapps.org/reef#rt> The link target is an application-specific semantic type of the link context. Multiple resource types can be specified, each as a link with the resource type as link target. The link target MUST NOT contain multiple resource types separated by white space. <http://coreapps.org/reef#if> The link target is a specific interface definition that can be used to interact with the link context. <http://coreapps.org/reef#sz> The link target is an indication of the maximum size of the resource representation returned by performing a GET on the link context. <http://coreapps.org/reef#ct> The link target is a hint about the Content-Formats that the link context returns. 4. Resource Discovery Given a host name or IP address, a client can discover the resources of a server implementing this section through the use of a well-known resource [RFC8615]. Well-known resources have a path component that Hartke Expires May 7, 2020 [Page 8]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 begins with "/.well-known/". This specification defines a new well- known resource for CoRE Resource Discovery: "/.well-known/core". 4.1. Well-known Resource The "/.well-known/core" resource is offered by servers implementing this specification on the default port appropriate for the protocol for the purpose of resource discovery. It is up to the server to decide which of the resources in its namespace are included; the "/.well-known/core" resource is generally meant to provide entry points to applications hosted by the server. A client wishing to discover the resources of a server constructs the URI <{scheme}://{host}:{port}/.well-known/core> from the scheme, host name/IP address, and port. The client then retrieves a CoRAL document from this URI, as specified in [I-D.ietf-core-coral]. The document contains a list of links, each from the well-known resource to one resource hosted by the server, along with resource metadata. The client can filter the list using a number of query parameters. 4.1.1. Resource List Representation A list of resources is represented as a CoRAL document [I-D.ietf-core-coral] containing the following elements: o For each resource that the server wishes to advertise to the client, a link of type <http://coreapps.org/reef#rd-item> targeting that resource. The link MUST target a resource in the namespace of the server (same origin). The link MAY have nested links providing resource metadata (including, but not limited to, the resource metadata specified in Section 3). Hartke Expires May 7, 2020 [Page 9]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 4.2. Interactions 4.2.1. Getting All Resources A client can get a list of all resources by making a GET request to <{scheme}://{host}:{port}/.well-known/core>. The request MUST include an Accept option with value TBD3. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1) that the server wishes to advertise to the client. Example: => 0.01 GET Uri-Path: .well-known Uri-Path: core Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using base = <http://coreapps.org/base#> #using iana = <http://www.iana.org/assignments/relation/> rd-item </sensors> { ct 40 base:title "Sensor Index" } rd-item </sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } rd-item </sensors/light> { rt "light-lux" if "sensor" } Hartke Expires May 7, 2020 [Page 10]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 4.2.2. Getting Resources By Resource Type A client can filter a list of resources by resource type by making a GET request to <{scheme}://{host}:{port}/.well-known/ core?rt={value}>. The request MUST include an Accept option with value TBD3. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type <http://coreapps.org/reef#rt> with the specified text value. Example: => 0.01 GET Uri-Path: .well-known Uri-Path: core Uri-Query: rt=temperature-c Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using iana = <http://www.iana.org/assignments/relation/> rd-item </sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } Hartke Expires May 7, 2020 [Page 11]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 4.2.3. Getting Resources By Interface Type A client can filter a list of resources by interface type by making a GET request to <{scheme}://{host}:{port}/.well-known/ core?if={value}>. The request MUST include an Accept option with value TBD3. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type <http://coreapps.org/reef#if> with the specified text value. Example: => 0.01 GET Uri-Path: .well-known Uri-Path: core Uri-Query: if=sensor Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using iana = <http://www.iana.org/assignments/relation/> rd-item </sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } rd-item </sensors/light> { rt "light-lux" if "sensor" } Hartke Expires May 7, 2020 [Page 12]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5. Resource Directory A resource directory provides information about entry points to applications hosted by other servers. It is intended to make discovery operations more efficient than retrieving each "/.well- known/core" of these servers individually. 5.1. Resource Lookups A client wishing to discover resources using a resource directory needs to be pre-configured with the URI of a resource directory or acquire the URI through some discovery process. The client then retrieves a CoRAL document from this URI, as specified in [I-D.ietf-core-coral]. The document contains a list of links, each from the resource directory to one of the resources in the directory, along with any registered resource metadata. The client can filter the list either by using a number of query parameters or by submitting a filter query. 5.1.1. Filter Query Representation TODO. 5.2. Resource Registrations A server (or a third party acting on behalf of a server) can register resources with a resource directory by submitting a CoRAL document, containing the new links to be created at the directory. The directory processes the submitted links in two ways: First, it includes those links in the list of results to client queries. Second, it creates a resource containing the group of submitted links, such that the server (or third party) can easily update or delete the whole group as a single unit at a later time. 5.2.1. Registration Unit Representation A registration unit is represented as a CoRAL document [I-D.ietf-core-coral] containing the registered resources as top- level element. A registered resource is represented as a link where the link relation type is <http://coreapps.org/reef#rd-item> and the link target is the registered resource. This link MAY have metadata about the resource (including, but not limited to, of the type specified in Section 3) as nested elements. Hartke Expires May 7, 2020 [Page 13]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.2.2. Registration Unit List Representation A list of registration units is represented as a CoRAL document [I-D.ietf-core-coral] containing the units in the list as top-level elements. Each registration unit is represented as a link where the link relation type is <http://coreapps.org/reef#rd-unit> and the link target is the registration unit URI. Hartke Expires May 7, 2020 [Page 14]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3. Interactions 5.3.1. Getting All Resources A client can get a list of all resources by making a GET request to the lookup URI. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1). Example: => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: lookup Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using base = <http://coreapps.org/base#> #using iana = <http://www.iana.org/assignments/relation/> rd-item <coap://[2001:db8:1::1]/sensors> { ct 40 base:title "Sensor Index" } rd-item <coap://[2001:db8:1::1]/sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } rd-item <coap://[2001:db8:1::1]/sensors/light> { rt "light-lux" if "sensor" } Hartke Expires May 7, 2020 [Page 15]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.2. Getting Resources By Resource Type A client can filter a list of resources by resource type by making a GET request to the result of resolving <?rt={value}> relative to the lookup URI. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type <http://coreapps.org/reef#rt> with the specified text value. Example: => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: lookup Uri-Query: rt=temperature-c Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using iana = <http://www.iana.org/assignments/relation/> rd-item <coap://[2001:db8:1::1]/sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } Hartke Expires May 7, 2020 [Page 16]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.3. Getting Resources By Interface Type A client can filter a list of resources by interface type by making a GET request to the result of resolving <?if={value}> relative to the lookup URI. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1), but containing only the subset of links that has resource metadata of type <http://coreapps.org/reef#if> with the specified text value. Example: => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: lookup Uri-Query: if=sensor Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using iana = <http://www.iana.org/assignments/relation/> rd-item <coap://[2001:db8:1::1]/sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } rd-item <coap://[2001:db8:1::1]/sensors/light> { rt "light-lux" if "sensor" } Hartke Expires May 7, 2020 [Page 17]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.4. Getting Resources By Resource Metadata A client can filter a list of resources by submitting the representation of a metadata filter (see Section 5.1.1) in a FETCH request to the lookup URI. On success, the server returns a 2.05 (Content) response with a representation of the list of resources (see Section 4.1.1) that match the filter. Example: => 0.05 FETCH Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: lookup Content-Format: TODO Accept: TBD3 TODO <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> #using iana = <http://www.iana.org/assignments/relation/> rd-item <coap://[2001:db8:1::1]/sensors/temp> { rt "temperature-c" if "sensor" iana:describedby <http://www.example.com/sensors/t123> iana:alternate </t> } Hartke Expires May 7, 2020 [Page 18]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.5. Getting All Registration Units A client can list a collection of registration units by making a GET request to the collection URI. On success, the server returns a 2.05 (Content) response with a representation of the list of all registration units (see Section 5.2.2) in the collection. Example: => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #using <http://coreapps.org/reef#> rd-unit <./1> rd-unit <./2> rd-unit <./3> rd-unit <./4> Hartke Expires May 7, 2020 [Page 19]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.6. Creating a Registration Unit A client can add a new registration unit to a collection of registration units by submitting a representation of the unit (see Section 5.2.1) in a POST request to the registration collection URI. On success, the server returns a 2.01 (Created) response indicating the registration unit URI of the new registration unit. Example: => 0.02 POST Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Content-Format: TBD3 #base <coap://[2001:db8:4::1]/> rd-item </light/left> { rt "light" ct 0 } rd-item </light/middle> { rt "light" ct 0 } rd-item </light/right> { rt "light" ct 0 } <= 2.01 Created Location-Path: path Location-Path: to Location-Path: resource Location-Path: directory Location-Path: registrations Location-Path: 42 Hartke Expires May 7, 2020 [Page 20]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.7. Reading a Registration Unit A client can read a registration unit by making a GET request to the registration unit URI. On success, the server returns a 2.05 (Content) response with a representation of the registration unit (see Section 5.2.1). Example: => 0.01 GET Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Uri-Path: 42 Accept: TBD3 <= 2.05 Content Content-Format: TBD3 #base <coap://[2001:db8:4::1]> rd-item </light/left> { rt "light" ct 0 } rd-item </light/middle> { rt "light" ct 0 } rd-item </light/right> { rt "light" ct 0 } Hartke Expires May 7, 2020 [Page 21]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.8. Updating a Registration Unit A client can update a resource registration by submitting the representation of the updated registration (see Section 5.2.1) in a PUT request to the topic URI. Any existing registrations in the registration unit are replaced by this update. On success, the server returns a 2.04 (Updated) response. Example: => 0.03 PUT Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Uri-Path: 42 Content-Format: TBD3 #base <coap://[2001:db8:4::1]/> rd-item </light/left> { rt "light" ct 0 } rd-item </light/right> { rt "light" ct 0 } <= 2.04 Changed Hartke Expires May 7, 2020 [Page 22]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 5.3.9. Deleting a Registration Unit A client can delete a registration unit by making a DELETE request on the registration unit URI. On success, the server returns a 2.02 (Deleted) response. Example: => 0.04 DELETE Uri-Path: path Uri-Path: to Uri-Path: resource Uri-Path: directory Uri-Path: registrations Uri-Path: 42 <= 2.02 Deleted Hartke Expires May 7, 2020 [Page 23]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 6. Security Considerations TODO. 7. IANA Considerations 7.1. CoRE Dictionary This document creates a new registry named "CoRAL Dictionary for CoRE" under the Constrained RESTful Environments (CoRE) Parameters" registry [CORE-PARAMETERS] for use with the CoRAL binary format [I-D.ietf-core-coral]. The registry is located at <http://TBD5/>. [[NOTE TO RFC EDITOR: Please replace all occurrences of "http://TBD5/" in this document with the URI of the new registry.]] The registry is a mapping between a key and a value. The key is an integer in the range 0 to 2147483647 (2^31-1). The value is either an Internationalized Resource Identifier (IRI) reference, a Boolean value, an integer, a floating-point number, a date/time value, a byte string, or a text string. Both the key and the value are to be denoted in the CoRAL textual format [I-D.ietf-core-coral] and must be unique within the registry. A reference may be provided to offer more information about a value. The registry policy is Expert Review. The initial entries in the registry are as follows: o Key: 0 Value: <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> Reference: [W3C.REC-rdf-schema-20140225] o Key: 1 Value: <http://www.iana.org/assignments/relation/item> Reference: [RFC6573] o Key: 2 Value: <http://www.iana.org/assignments/relation/collection> Reference: [RFC6573] o Key: 3 Value: <http://coreapps.org/collections#create> Reference: [I-D.ietf-core-coral] o Key: 4 Value: <http://coreapps.org/base#update> Reference: [I-D.ietf-core-coral] Hartke Expires May 7, 2020 [Page 24]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 o Key: 5 Value: <http://coreapps.org/collections#delete> Reference: [I-D.ietf-core-coral] o Key: 6 Value: <http://coreapps.org/base#search> Reference: [I-D.ietf-core-coral] o Key: 7 Value: <http://coreapps.org/coap#accept> Reference: [I-D.ietf-core-coral] o Key: 8 Value: <http://coreapps.org/reef#rd-unit> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 9 Value: <http://coreapps.org/reef#rd-item> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 10 Value: <http://coreapps.org/base#language> Reference: [I-D.ietf-core-coral] o Key: 11 Value: <http://coreapps.org/reef#media> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 12 Value: <http://coreapps.org/base#title> Reference: [I-D.ietf-core-coral] o Key: 13 Value: <http://coreapps.org/coap#type> Reference: [I-D.ietf-core-coral] o Key: 14 Value: <http://coreapps.org/reef#rt> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 15 Value: <http://coreapps.org/reef#if> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 16 Value: <http://coreapps.org/reef#sz> Reference: [I-D.hartke-t2trg-coral-reef] Hartke Expires May 7, 2020 [Page 25]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 o Key: 17 Value: <http://coreapps.org/reef#ct> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 18 Value: </.well-known/core> Reference: [I-D.hartke-t2trg-coral-reef] o Key: 19 Value: <http://coreapps.org/base#direction> Reference: [I-D.ietf-core-coral] o Key: 20 Value: "ltr" Reference: o Key: 21 Value: "rtl" Reference: 7.2. CoAP Content Format This document registers a CoAP content format for CoRAL documents in the binary format that use the registry established in Section 7.1. The registration is in accordance with the procedures of RFC 7252 [RFC7252]. o Content Type: application/coral+cbor;dictionary="http://TBD5/" Content Coding: identity ID: TBD3 Reference: [I-D.hartke-t2trg-coral-reef] [[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD3" in this document with the code point assigned by IANA.]] [[NOTE TO IMPLEMENTERS: Experimental implementations can use content format ID 65088 until IANA has assigned a code point.]] 8. References 8.1. Normative References [I-D.ietf-core-coral] Hartke, K., "The Constrained RESTful Application Language (CoRAL)", draft-ietf-core-coral-01 (work in progress), November 2019. Hartke Expires May 7, 2020 [Page 26]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 [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/info/rfc2119>. [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/info/rfc7252>. [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/info/rfc8174>. [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>. 8.2. Informative References [CORE-PARAMETERS] IANA, "Constrained RESTful Environments (CoRE) Parameters", <http://www.iana.org/assignments/core-parameters>. [I-D.ietf-core-resource-directory] Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Amsuess, "CoRE Resource Directory", draft-ietf-core- resource-directory-23 (work in progress), July 2019. [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>. [RFC6573] Amundsen, M., "The Item and Collection Link Relations", RFC 6573, DOI 10.17487/RFC6573, April 2012, <https://www.rfc-editor.org/info/rfc6573>. [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>. Hartke Expires May 7, 2020 [Page 27]
Internet-Draft CoRE Resource Discovery using CoRAL November 2019 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>. [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>. [W3C.REC-rdf-schema-20140225] Brickley, D. and R. Guha, "RDF Schema 1.1", World Wide Web Consortium Recommendation REC-rdf-schema-20140225, February 2014, <http://www.w3.org/TR/2014/REC-rdf-schema-20140225>. Acknowledgements Thanks to Christian Amsuess and Carsten Bormann for helpful comments and discussions that have shaped the document. Author's Address Klaus Hartke Ericsson Torshamnsgatan 23 Stockholm SE-16483 Sweden Email: klaus.hartke@ericsson.com Hartke Expires May 7, 2020 [Page 28]