< draft-hartke-t2trg-coral-reef-01.txt   draft-hartke-t2trg-coral-reef-02.txt >
Thing-to-Thing Research Group K. Hartke Thing-to-Thing Research Group K. Hartke
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Experimental March 11, 2019 Intended status: Experimental July 8, 2019
Expires: September 12, 2019 Expires: January 9, 2020
Resource Discovery in Constrained RESTful Environments (CoRE) Resource Discovery in Constrained RESTful Environments (CoRE)
Using the Constrained RESTful Application Language (CoRAL) using the Constrained RESTful Application Language (CoRAL)
draft-hartke-t2trg-coral-reef-01 draft-hartke-t2trg-coral-reef-02
Abstract Abstract
This document explores how the Constrained RESTful Application This document explores how the Constrained RESTful Application
Language (CoRAL) might be used for two use cases in Constrained Language (CoRAL) might be used for two use cases in Constrained
RESTful Environments (CoRE): CoRE Resource Discovery, which allows a RESTful Environments (CoRE): CoRE Resource Discovery, which allows a
client to discover the resources of a server given a host name or IP client to discover the resources of a server given a host name or IP
address, and CoRE Resource Directory, which provides a directory of address, and CoRE Resource Directory, which provides a directory of
resources on many servers. resources on many servers.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 12, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 13 skipping to change at page 2, line 13
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 3 2.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 3
2.2. Resource Directory . . . . . . . . . . . . . . . . . . . 5 2.2. Resource Directory . . . . . . . . . . . . . . . . . . . 5
2.3. Notational Conventions . . . . . . . . . . . . . . . . . 6 2.3. Notational Conventions . . . . . . . . . . . . . . . . . 7
3. Resource Metadata . . . . . . . . . . . . . . . . . . . . . . 6 3. Resource Metadata . . . . . . . . . . . . . . . . . . . . . . 7
4. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 7 4. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 8
4.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 8 4.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 8
4.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 9 4.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 9 4.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 9
4.2.2. Get Resources By Resource Type . . . . . . . . . . . 10 4.2.2. Get Resources By Resource Type . . . . . . . . . . . 10
4.2.3. Get Resources By Interface Type . . . . . . . . . . . 11 4.2.3. Get Resources By Interface Type . . . . . . . . . . . 11
5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 12 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 12
5.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 12 5.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 12
5.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 13 5.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 13
5.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 13 5.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 13
5.2.2. Get Resources By Resource Type . . . . . . . . . . . 14 5.2.2. Get Resources By Resource Type . . . . . . . . . . . 14
skipping to change at page 4, line 19 skipping to change at page 4, line 19
"/.well-known/core". The representation contains a list of links to "/.well-known/core". The representation contains a list of links to
the resources of interest on the server, which are typically entry the resources of interest on the server, which are typically entry
points to the different applications hosted by the server. The links points to the different applications hosted by the server. The links
may have nested resource metadata. A client would then find an may have nested resource metadata. A client would then find an
appropriate resource based on the metadata. Metadata queries may appropriate resource based on the metadata. Metadata queries may
also be specified the query string to filter the result set. also be specified the query string to filter the result set.
The following example shows how a client discovers the resources of a The following example shows how a client discovers the resources of a
CoAP server by making a GET request to the "/.well-known/core" CoAP server by making a GET request to the "/.well-known/core"
resource. The client receives a 2.05 (Content) response with a list resource. The client receives a 2.05 (Content) response with a list
of links of type <http://TBD6/rd-item>. The links contain nested of links of type <http://coreapps.org/reef#rd-item>. The links
elements with resource metadata (such as resource type, interface contain nested elements with resource metadata (such as resource
description, available content formats, and related resources). type, interface description, available content formats, and related
resources).
=> 0.01 GET => 0.01 GET
Uri-Path: .well-known Uri-Path: .well-known
Uri-Path: core Uri-Path: core
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item </sensors> { rd-item </sensors> {
ct 40 ct 40
title "Sensor Index" title "Sensor Index"
} }
rd-item </sensors/temp> { rd-item </sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
skipping to change at page 5, line 28 skipping to change at page 5, line 32
entities that store links to resources stored on other servers. A entities that store links to resources stored on other servers. A
resource directory can be thought of as a limited search engine for resource directory can be thought of as a limited search engine for
M2M resources. M2M resources.
In this specification, a resource directory provides the same lookup In this specification, a resource directory provides the same lookup
interface as a "/.well-known/core" resource, except that it provides interface as a "/.well-known/core" resource, except that it provides
links to resources on potentially many different servers. For links to resources on potentially many different servers. For
populating the resource directory, a registration interface is populating the resource directory, a registration interface is
offered. The registration interface is a collection resource with offered. The registration interface is a collection resource with
the common operations of create, read, update, and delete. The items the common operations of create, read, update, and delete. The items
of the collection are groups of links of type <http://TBD6/rd-item> of the collection are groups of links of type <http://coreapps.org/
that are to be made available in the lookup interface. reef#rd-item> that are to be made available in the lookup interface.
The following example shows how a client registers a group of links The following example shows how a client registers a group of links
with a CoAP resource directory by making a POST request to the with a CoAP resource directory by making a POST request to the
collection resource. The client receives a 2.01 (Created) response collection resource. The client receives a 2.01 (Created) response
with the location of the created collection item. The client can use with the location of the created collection item. The client can use
this location later to update the group of links or delete them from this location later to update the group of links or delete them from
the directory. the directory.
=> 0.02 POST => 0.02 POST
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#base <coap://[2001:db8:3::124]/> #base <coap://[2001:db8:3::124]/>
rd-item </light/left> { rt "light-lux" ct 0 } rd-item </light/left> { rt "light-lux" ct 0 }
rd-item </light/middle> { rt "light-lux" ct 0 } rd-item </light/middle> { rt "light-lux" ct 0 }
rd-item </light/right> { rt "light-lux" ct 0 } rd-item </light/right> { rt "light-lux" ct 0 }
<= 2.01 Created <= 2.01 Created
Location-Path: path Location-Path: path
Location-Path: to Location-Path: to
Location-Path: resource Location-Path: resource
skipping to change at page 6, line 29 skipping to change at page 6, line 43
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Uri-Query: rt=light-lux Uri-Query: rt=light-lux
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#base <coap://[2001:db8:1::9]/> #base <coap://[2001:db8:1::9]/>
rd-item </1234> { rt "light-lux" } rd-item </1234> { rt "light-lux" }
#base <coap://[2001:db8:3::124]/> #base <coap://[2001:db8:3::124]/>
rd-item </light/left> { rt "light-lux" ct 0 } rd-item </light/left> { rt "light-lux" ct 0 }
rd-item </light/middle> { rt "light-lux" ct 0 } rd-item </light/middle> { rt "light-lux" ct 0 }
rd-item </light/right> { rt "light-lux" ct 0 } rd-item </light/right> { rt "light-lux" ct 0 }
2.3. Notational Conventions 2.3. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Resource Metadata 3. Resource Metadata
Both "/.well-known/core" resources and resource directories link to Both "/.well-known/core" resources and resource directories link to
resources of interest using the <http://TBD6/rd-item> link relation resources of interest using the <http://coreapps.org/reef#rd-item>
type. Metadata for these resources can be expressed by nesting link relation type. Metadata for these resources can be expressed by
further links inside these links. nesting further links inside these links.
The following link relation types for resource metadata are defined: The following link relation types for resource metadata are defined:
<http://TBD6/hreflang> <http://coreapps.org/base#lang>
The link target is a hint indicating what the (human-spoken) The link target is a hint indicating what the (human-spoken)
language of the result of dereferencing the link context should language of the result of dereferencing the link context should
be. be.
<http://TBD6/media> <http://coreapps.org/reef#media>
The link target indicates the intended destination medium or media The link target indicates the intended destination medium or media
for style information for the link context. for style information for the link context.
<http://TBD6/title> <http://coreapps.org/reef#title>
The link target is a label that it can be used as a human-readable The link target is a label that it can be used as a human-readable
identifier for the link context. identifier for the link context.
The link can have a nested link containing language information. The link can have a nested link containing language information.
<http://TBD6/type> <http://coreapps.org/coap#type>
The link target is a hint indicating what the media type of the The link target is a hint indicating what the media type of the
result of dereferencing the link context should be. result of dereferencing the link context should be.
<http://TBD6/rt> <http://coreapps.org/reef#rt>
The link target is an application-specific semantic type of the The link target is an application-specific semantic type of the
link context. link context.
Multiple resource types can be specified, each as a link with the Multiple resource types can be specified, each as a link with the
resource type as link target. The link target MUST NOT contain resource type as link target. The link target MUST NOT contain
multiple resource types separated by white space. multiple resource types separated by white space.
<http://TBD6/if> <http://coreapps.org/reef#if>
The link target is a specific interface definition that can be The link target is a specific interface definition that can be
used to interact with the link context. used to interact with the link context.
<http://TBD6/sz> <http://coreapps.org/reef#sz>
The link target is an indication of the maximum size of the The link target is an indication of the maximum size of the
resource representation returned by performing a GET on the link resource representation returned by performing a GET on the link
context. context.
<http://TBD6/ct> <http://coreapps.org/reef#ct>
The link target is a hint about the Content-Formats that the link The link target is a hint about the Content-Formats that the link
context returns. context returns.
4. Resource Discovery 4. Resource Discovery
Given a host name or IP address, a client can discover the resources 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 of a server implementing this section through the use of a well-known
resource [I-D.nottingham-rfc5785bis]. Well-known resources have a resource [RFC8615]. Well-known resources have a path component that
path component that begins with "/.well-known/". This specification begins with "/.well-known/". This specification defines a new well-
defines a new well-known resource for CoRE Resource Discovery: known resource for CoRE Resource Discovery: "/.well-known/core".
"/.well-known/core".
4.1. How It Works 4.1. How It Works
A server implementing this specification offers a "/.well-known/core" A server implementing this specification offers a "/.well-known/core"
resource on the default port appropriate for the protocol for the resource on the default port appropriate for the protocol for the
purpose of resource discovery. It is up to the server which of the purpose of resource discovery. It is up to the server which of the
resources in its namespace are included; the "/.well-known/core" resources in its namespace are included; the "/.well-known/core"
resource is generally meant to provide entry points to applications resource is generally meant to provide entry points to applications
hosted by the server. hosted by the server.
skipping to change at page 9, line 20 skipping to change at page 9, line 20
Request Method: GET Request Method: GET
URI Template: coap://{host-and-port}/.well-known/core URI Template: coap://{host-and-port}/.well-known/core
Accept Option: TBD3 Accept Option: TBD3
Response Response
When successful, the server returns a 2.05 (Content) response with When successful, the server returns a 2.05 (Content) response with
a representation in content format TBD3 ('application/coral+cbor; a representation in content format TBD3. The representation MUST
dictionary=http://TBD5/'). The representation MUST contain zero contain zero or more links of type <http://coreapps.org/reef#rd-
or more links of type <http://TBD6/rd-item>, each of which MUST item>, each of which MUST target a resource in the namespace of
target a resource in the namespace of the server (same origin). the server (same origin). The links may have nested elements
The links may have nested elements providing resource metadata. providing resource metadata.
Example Example
=> 0.01 GET => 0.01 GET
Uri-Path: .well-known Uri-Path: .well-known
Uri-Path: core Uri-Path: core
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item </sensors> { rd-item </sensors> {
ct 40 ct 40
title "Sensor Index" title "Sensor Index"
} }
rd-item </sensors/temp> { rd-item </sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
skipping to change at page 10, line 30 skipping to change at page 10, line 30
=> 0.01 GET => 0.01 GET
Uri-Path: .well-known Uri-Path: .well-known
Uri-Path: core Uri-Path: core
Uri-Query: rt=temperature-c Uri-Query: rt=temperature-c
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item </sensors/temp> { rd-item </sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
iana:alternate </t> iana:alternate </t>
} }
4.2.3. Get Resources By Interface Type 4.2.3. Get Resources By Interface Type
skipping to change at page 11, line 30 skipping to change at page 11, line 30
=> 0.01 GET => 0.01 GET
Uri-Path: .well-known Uri-Path: .well-known
Uri-Path: core Uri-Path: core
Uri-Query: if=sensor Uri-Query: if=sensor
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item </sensors/temp> { rd-item </sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
iana:alternate </t> iana:alternate </t>
} }
rd-item </sensors/light> { rd-item </sensors/light> {
rt "light-lux" rt "light-lux"
skipping to change at page 13, line 33 skipping to change at page 13, line 33
=> 0.01 GET => 0.01 GET
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item <coap://[2001:db8:1::1]/sensors> { rd-item <coap://[2001:db8:1::1]/sensors> {
ct 40 ct 40
title "Sensor Index" title "Sensor Index"
} }
rd-item <coap://[2001:db8:1::1]/sensors/temp> { rd-item <coap://[2001:db8:1::1]/sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
skipping to change at page 14, line 32 skipping to change at page 14, line 32
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Uri-Query: rt=temperature-c Uri-Query: rt=temperature-c
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item <coap://[2001:db8:1::1]/sensors/temp> { rd-item <coap://[2001:db8:1::1]/sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
iana:alternate </t> iana:alternate </t>
} }
5.2.3. Get Resources By Interface Type 5.2.3. Get Resources By Interface Type
skipping to change at page 15, line 32 skipping to change at page 15, line 32
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Uri-Query: if=sensor Uri-Query: if=sensor
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
#using iana = <http://www.iana.org/assignments/relation/> #using iana = <http://www.iana.org/assignments/relation/>
rd-item <coap://[2001:db8:1::1]/sensors/temp> { rd-item <coap://[2001:db8:1::1]/sensors/temp> {
rt "temperature-c" rt "temperature-c"
if "sensor" if "sensor"
iana:describedby <http://www.example.com/sensors/t123> iana:describedby <http://www.example.com/sensors/t123>
iana:alternate </t> iana:alternate </t>
} }
rd-item <coap://[2001:db8:1::1]/sensors/light> { rd-item <coap://[2001:db8:1::1]/sensors/light> {
rt "light-lux" rt "light-lux"
skipping to change at page 16, line 19 skipping to change at page 16, line 19
Request Method: GET Request Method: GET
URI Template: {resource-directory-location} URI Template: {resource-directory-location}
Accept Option: TBD3 Accept Option: TBD3
Response Response
When successful, the server returns a 2.05 (Content) response with When successful, the server returns a 2.05 (Content) response with
a representation in content format TBD3. The representation a representation in content format TBD3. The representation
contains or zero or more links with the <http://TBD6/rd-unit> link contains or zero or more links with the <http://coreapps.org/
relation type, each of which has a resource registration as the reef#rd-unit> link relation type, each of which has a resource
link target. registration as the link target.
Example Example
=> 0.01 GET => 0.01 GET
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
Uri-Path: resource Uri-Path: resource
Uri-Path: directory Uri-Path: directory
Accept: TBD3 Accept: TBD3
<= 2.05 Content <= 2.05 Content
Content-Format: TBD3 Content-Format: TBD3
#using <http://TBD6/> #using <http://coreapps.org/reef#>
rd-unit </rd/1> rd-unit </rd/1>
rd-unit </rd/2> rd-unit </rd/2>
rd-unit </rd/3> rd-unit </rd/3>
rd-unit </rd/4> rd-unit </rd/4>
5.2.5. Create Resource Registration 5.2.5. Create Resource Registration
Request Request
Request Method: POST Request Method: POST
URI Template: {resource-directory-location} URI Template: {resource-directory-location}
Content-Format Option: TBD3 Content-Format Option: TBD3
The client submits a representation in content format TBD3. The The client submits a representation in content format TBD3. The
representation contains zero or more links with the <http://TBD6/ representation contains zero or more links with the
rd-item> link relation type, each of which has a resource to be <http://coreapps.org/reef#rd-item> link relation type, each of
registered as the link target. which has a resource to be registered as the link target.
Response Response
When successful, the server returns a 2.01 (Created) response When successful, the server returns a 2.01 (Created) response
indicating the location at which the resource registration was indicating the location at which the resource registration was
created. created.
Example Example
=> 0.02 POST => 0.02 POST
skipping to change at page 19, line 16 skipping to change at page 19, line 16
Request Request
Request Method: PUT Request Method: PUT
URI Template: {registration-location} URI Template: {registration-location}
Content-Format Option: TBD3 Content-Format Option: TBD3
The client submits a representation in content format TBD3. The The client submits a representation in content format TBD3. The
representation contains zero or more links with the <http://TBD6/ representation contains zero or more links with the
rd-item> link relation type, each of which has a resource to be <http://coreapps.org/reef#rd-item> link relation type, each of
registered as the link target. Any existing list of resources at which has a resource to be registered as the link target. Any
the location is replaced by this update. existing list of resources at the location is replaced by this
update.
Response Response
When successful, the server returns a 2.04 (Changed) response. When successful, the server returns a 2.04 (Changed) response.
Example Example
=> 0.03 PUT => 0.03 PUT
Uri-Path: path Uri-Path: path
Uri-Path: to Uri-Path: to
skipping to change at page 21, line 18 skipping to change at page 21, line 18
7. IANA Considerations 7. IANA Considerations
7.1. CoRE Dictionary 7.1. CoRE Dictionary
This document creates a new registry named "CoRAL Dictionary for This document creates a new registry named "CoRAL Dictionary for
CoRE" under the Constrained RESTful Environments (CoRE) Parameters" CoRE" under the Constrained RESTful Environments (CoRE) Parameters"
registry [CORE-PARAMETERS] for use with the CoRAL binary format registry [CORE-PARAMETERS] for use with the CoRAL binary format
[I-D.hartke-t2trg-coral]. The registry is located at <http://TBD5/>. [I-D.hartke-t2trg-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 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 integer in the range 0 to 2147483647 (2^31-1). The value is either
an Internationalized Resource Identifier (IRI) reference, a Boolean an Internationalized Resource Identifier (IRI) reference, a Boolean
value, an integer, a floating-point number, a date/time value, a byte 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 string, or a text string. Both the key and the value are to be
denoted in the CoRAL textual format [I-D.hartke-t2trg-coral] and must denoted in the CoRAL textual format [I-D.hartke-t2trg-coral] and must
be unique within the registry. A reference may be provided to offer be unique within the registry. A reference may be provided to offer
more information about a value. more information about a value.
The registry policy is Expert Review. The registry policy is Expert Review.
skipping to change at page 21, line 44 skipping to change at page 21, line 47
o Key: 1 o Key: 1
Value: <http://www.iana.org/assignments/relation/item> Value: <http://www.iana.org/assignments/relation/item>
Reference: [RFC6573] Reference: [RFC6573]
o Key: 2 o Key: 2
Value: <http://www.iana.org/assignments/relation/collection> Value: <http://www.iana.org/assignments/relation/collection>
Reference: [RFC6573] Reference: [RFC6573]
o Key: 3 o Key: 3
Value: <urn:TBD1#create> Value: <http://coreapps.org/collections#create>
Reference: [I-D.hartke-t2trg-coral] Reference: [I-D.hartke-t2trg-coral]
o Key: 4 o Key: 4
Value: <urn:TBD1#update> Value: <http://coreapps.org/base#update>
Reference: [I-D.hartke-t2trg-coral] Reference: [I-D.hartke-t2trg-coral]
o Key: 5 o Key: 5
Value: <urn:TBD1#delete> Value: <http://coreapps.org/collections#delete>
Reference: [I-D.hartke-t2trg-coral] Reference: [I-D.hartke-t2trg-coral]
o Key: 6 o Key: 6
Value: <urn:TBD1#search> Value: <http://coreapps.org/base#search>
Reference: [I-D.hartke-t2trg-coral] Reference: [I-D.hartke-t2trg-coral]
o Key: 7 o Key: 7
Value: <urn:TBD1#accept> Value: <http://coreapps.org/coap#accept>
Reference: [I-D.hartke-t2trg-coral] Reference: [I-D.hartke-t2trg-coral]
o Key: 8 o Key: 8
Value: <http://TBD6/rd-unit> Value: <http://coreapps.org/reef#rd-unit>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 9 o Key: 9
Value: <http://TBD6/rd-item> Value: <http://coreapps.org/reef#rd-item>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 10 o Key: 10
Value: <http://TBD6/hreflang> Value: <http://coreapps.org/base#lang>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral]
o Key: 11 o Key: 11
Value: <http://TBD6/media> Value: <http://coreapps.org/reef#media>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 12 o Key: 12
Value: <http://TBD6/title> Value: <http://coreapps.org/reef#title>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 13 o Key: 13
Value: <http://TBD6/type> Value: <http://coreapps.org/coap#type>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral]
o Key: 14 o Key: 14
Value: <http://TBD6/rt> Value: <http://coreapps.org/reef#rt>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 15 o Key: 15
Value: <http://TBD6/if> Value: <http://coreapps.org/reef#if>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 16 o Key: 16
Value: <http://TBD6/sz> Value: <http://coreapps.org/reef#sz>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 17 o Key: 17
Value: <http://TBD6/ct> Value: <http://coreapps.org/reef#ct>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
o Key: 18 o Key: 18
Value: </.well-known/core> Value: </.well-known/core>
Reference: [I-D.hartke-t2trg-coral-reef] Reference: [I-D.hartke-t2trg-coral-reef]
7.2. CoAP Content Format 7.2. CoAP Content Format
This document registers a CoAP content format for CoRAL documents in This document registers a CoAP content format for CoRAL documents in
the binary format that use the registry established in Section 7.1. the binary format that use the registry established in Section 7.1.
The registration is in accordance with the procedures of RFC 7252 The registration is in accordance with the procedures of RFC 7252
[RFC7252]. [RFC7252].
o Content Type: application/coral+cbor; dictionary=http://TBD5/ o Content Type: application/coral+cbor;dictionary="http://TBD5/"
Content Coding: identity Content Coding: identity
ID: TBD3 ID: TBD3
Reference: [I-D.hartke-t2trg-coral-reef] [I-D.hartke-t2trg-coral] 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. References
8.1. Normative References 8.1. Normative References
[I-D.hartke-t2trg-coral] [I-D.hartke-t2trg-coral]
Hartke, K., "The Constrained RESTful Application Language Hartke, K., "The Constrained RESTful Application Language
(CoRAL)", draft-hartke-t2trg-coral-08 (work in progress), (CoRAL)", draft-hartke-t2trg-coral-09 (work in progress),
March 2019. July 2019.
[I-D.nottingham-rfc5785bis]
Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", draft-nottingham-rfc5785bis-09 (work in
progress), February 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6573] Amundsen, M., "The Item and Collection Link Relations",
RFC 6573, DOI 10.17487/RFC6573, April 2012,
<https://www.rfc-editor.org/info/rfc6573>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[W3C.REC-rdf-schema-20140225] [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
Brickley, D. and R. Guha, "RDF Schema 1.1", World Wide Web (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
Consortium Recommendation REC-rdf-schema-20140225, <https://www.rfc-editor.org/info/rfc8615>.
February 2014,
<http://www.w3.org/TR/2014/REC-rdf-schema-20140225>.
8.2. Informative References 8.2. Informative References
[CORE-PARAMETERS] [CORE-PARAMETERS]
IANA, "Constrained RESTful Environments (CoRE) IANA, "Constrained RESTful Environments (CoRE)
Parameters", Parameters",
<http://www.iana.org/assignments/core-parameters>. <http://www.iana.org/assignments/core-parameters>.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-19 (work in progress), January 2019. resource-directory-22 (work in progress), July 2019.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation, Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000, University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/ <http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>. fielding_dissertation.pdf>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <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 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <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 Acknowledgements
Thanks to Christian Amsuess and Carsten Bormann for helpful comments Thanks to Christian Amsuess and Carsten Bormann for helpful comments
and discussions that have shaped the document. and discussions that have shaped the document.
Author's Address Author's Address
Klaus Hartke Klaus Hartke
Ericsson Ericsson
Torshamnsgatan 23 Torshamnsgatan 23
 End of changes. 54 change blocks. 
89 lines changed or deleted 98 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/