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]