draft-ietf-core-resource-directory-16.txt   draft-ietf-core-resource-directory-17.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Standards Track M. Koster Intended status: Standards Track M. Koster
Expires: April 26, 2019 SmartThings Expires: April 26, 2019 SmartThings
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
P. van der Stok P. van der Stok
consultant consultant
C. Amsuess, Ed. C. Amsuess, Ed.
October 23, 2018 October 23, 2018
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-16 draft-ietf-core-resource-directory-17
Abstract Abstract
In many M2M applications, direct discovery of resources is not In many M2M applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which hosts employing an entity called a Resource Directory (RD), which hosts
registrations of resources held on other servers, allowing lookups to registrations of resources held on other servers, allowing lookups to
be performed for those resources. This document specifies the web be performed for those resources. This document specifies the web
interfaces that a Resource Directory supports for web servers to interfaces that a Resource Directory supports for web servers to
skipping to change at page 2, line 24 skipping to change at page 2, line 24
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 7 3. Architecture and Use Cases . . . . . . . . . . . . . . . . . 6
3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Principles . . . . . . . . . . . . . . . . . . . . . . . 6
3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Architecture . . . . . . . . . . . . . . . . . . . . . . 7
3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 9 3.3. RD Content Model . . . . . . . . . . . . . . . . . . . . 8
3.4. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 13 3.4. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 12
3.5. Use Case: Home and Building Automation . . . . . . . . . 14 3.5. Use Case: Home and Building Automation . . . . . . . . . 13
3.6. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 14 3.6. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 13
4. Finding a Resource Directory . . . . . . . . . . . . . . . . 15 4. Finding a Resource Directory . . . . . . . . . . . . . . . . 14
4.1. Resource Directory Address Option (RDAO) . . . . . . . . 17 4.1. Resource Directory Address Option (RDAO) . . . . . . . . 15
5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 18 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 17
5.1. Payload Content Formats . . . . . . . . . . . . . . . . . 19 5.1. Payload Content Formats . . . . . . . . . . . . . . . . . 17
5.2. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 19 5.2. URI Discovery . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Registration . . . . . . . . . . . . . . . . . . . . . . 22 5.3. Registration . . . . . . . . . . . . . . . . . . . . . . 20
5.3.1. Simple Registration . . . . . . . . . . . . . . . . . 27 5.3.1. Simple Registration . . . . . . . . . . . . . . . . . 25
5.3.2. Third-party registration . . . . . . . . . . . . . . 29 5.3.2. Third-party registration . . . . . . . . . . . . . . 27
6. RD Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 30 5.3.3. RD-Groups . . . . . . . . . . . . . . . . . . . . . . 28
6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 30 6. RD Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 32 6.1. Resource lookup . . . . . . . . . . . . . . . . . . . . . 29
7. RD Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.2. Lookup filtering . . . . . . . . . . . . . . . . . . . . 30
7.1. Resource lookup . . . . . . . . . . . . . . . . . . . . . 33 6.3. Resource lookup examples . . . . . . . . . . . . . . . . 32
7.2. Lookup filtering . . . . . . . . . . . . . . . . . . . . 34 7. Security policies . . . . . . . . . . . . . . . . . . . . . . 35
7.3. Resource lookup examples . . . . . . . . . . . . . . . . 36 7.1. Secure RD discovery . . . . . . . . . . . . . . . . . . . 36
8. Security policies . . . . . . . . . . . . . . . . . . . . . . 39 7.2. Secure RD filtering . . . . . . . . . . . . . . . . . . . 37
8.1. Secure RD discovery . . . . . . . . . . . . . . . . . . . 40 7.3. Secure endpoint Name assignment . . . . . . . . . . . . . 37
8.2. Secure RD filtering . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
8.3. Secure endpoint Name assignment . . . . . . . . . . . . . 41 8.1. Endpoint Identification and Authentication . . . . . . . 38
9. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8.2. Access Control . . . . . . . . . . . . . . . . . . . . . 38
9.1. Endpoint Identification and Authentication . . . . . . . 41 8.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 38
9.2. Access Control . . . . . . . . . . . . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
9.3. Denial of Service Attacks . . . . . . . . . . . . . . . . 42 9.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9.2. IPv6 ND Resource Directory Address Option . . . . . . . . 39
10.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 43 9.3. RD Parameter Registry . . . . . . . . . . . . . . . . . . 39
10.2. IPv6 ND Resource Directory Address Option . . . . . . . 43 9.3.1. Full description of the "Endpoint Type" Registration
10.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 43 Parameter . . . . . . . . . . . . . . . . . . . . . . 42
10.3.1. Full description of the "Endpoint Type" Registration 9.4. "Endpoint Type" (et=) RD Parameter values . . . . . . . . 42
Parameter . . . . . . . . . . . . . . . . . . . . . 46 9.5. Multicast Address Registration . . . . . . . . . . . . . 43
10.4. "Endpoint Type" (et=) RD Parameter values . . . . . . . 46 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 43
10.5. Multicast Address Registration . . . . . . . . . . . . . 47 10.1. Lighting Installation . . . . . . . . . . . . . . . . . 43
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1.1. Installation Characteristics . . . . . . . . . . . . 43
11.1. Lighting Installation . . . . . . . . . . . . . . . . . 47 10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 44
11.1.1. Installation Characteristics . . . . . . . . . . . . 47 10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 47
11.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 48 10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 48
11.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 51 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 49
11.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 51
11.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 53 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 51
11.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
11.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 55 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 51
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 55 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 58
13. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 55 13.1. Normative References . . . . . . . . . . . . . . . . . . 58
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 62 13.2. Informative References . . . . . . . . . . . . . . . . . 59
14.1. Normative References . . . . . . . . . . . . . . . . . . 62 Appendix A. Registration Management . . . . . . . . . . . . . . 61
14.2. Informative References . . . . . . . . . . . . . . . . . 63 A.1. Registration Update . . . . . . . . . . . . . . . . . . . 62
Appendix A. Registration Management . . . . . . . . . . . . . . 65 A.2. Registration Removal . . . . . . . . . . . . . . . . . . 65
A.1. Registration Update . . . . . . . . . . . . . . . . . . . 65 A.3. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 66
A.2. Registration Removal . . . . . . . . . . . . . . . . . . 68 A.4. Update Endpoint Links . . . . . . . . . . . . . . . . . . 67
A.3. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 69 A.5. Endpoint lookup . . . . . . . . . . . . . . . . . . . . . 67
A.4. Update Endpoint Links . . . . . . . . . . . . . . . . . . 70 Appendix B. Web links and the Resource Directory . . . . . . . . 68
A.5. Endpoint and group lookup . . . . . . . . . . . . . . . . 71 B.1. A simple example . . . . . . . . . . . . . . . . . . . . 68
Appendix B. Web links and the Resource Directory . . . . . . . . 72 B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 69
B.1. A simple example . . . . . . . . . . . . . . . . . . . . 72 B.1.2. Interpreting attributes and relations . . . . . . . . 69
B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 73 B.2. A slightly more complex example . . . . . . . . . . . . . 69
B.1.2. Interpreting attributes and relations . . . . . . . . 73 B.3. Enter the Resource Directory . . . . . . . . . . . . . . 70
B.2. A slightly more complex example . . . . . . . . . . . . . 74
B.3. Enter the Resource Directory . . . . . . . . . . . . . . 74
B.4. A note on differences between link-format and Link B.4. A note on differences between link-format and Link
headers . . . . . . . . . . . . . . . . . . . . . . . . . 76 headers . . . . . . . . . . . . . . . . . . . . . . . . . 72
Appendix C. Syntax examples for Protocol Negotiation . . . . . . 77 Appendix C. Syntax examples for Protocol Negotiation . . . . . . 73
Appendix D. Modernized Link Format parsing . . . . . . . . . . . 78 Appendix D. Modernized Link Format parsing . . . . . . . . . . . 74
D.1. For endpoint developers . . . . . . . . . . . . . . . . . 79 D.1. For endpoint developers . . . . . . . . . . . . . . . . . 74
D.2. Examples of links with differing interpretations . . . . 79 D.2. Examples of links with differing interpretations . . . . 75
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 75
1. Introduction 1. Introduction
The work on Constrained RESTful Environments (CoRE) aims at realizing The work on Constrained RESTful Environments (CoRE) aims at realizing
the REST architecture in a suitable form for the most constrained the REST architecture in a suitable form for the most constrained
nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and nodes (e.g., 8-bit microcontrollers with limited RAM and ROM) and
networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M) networks (e.g. 6LoWPAN). CoRE is aimed at machine-to-machine (M2M)
applications such as smart energy and building automation. applications such as smart energy and building automation.
The discovery of resources offered by a constrained server is very The discovery of resources offered by a constrained server is very
skipping to change at page 5, line 20 skipping to change at page 5, line 17
implements the REST interfaces defined in this specification for implements the REST interfaces defined in this specification for
registration and lookup of those resources. registration and lookup of those resources.
Sector Sector
In the context of a Resource Directory, a sector is a logical In the context of a Resource Directory, a sector is a logical
grouping of endpoints. grouping of endpoints.
The abbreviation "d=" is used for the sector in query parameters The abbreviation "d=" is used for the sector in query parameters
for compatibility with deployed implementations. for compatibility with deployed implementations.
Group
A group in the Resource Directory specifies a set of endpoints
that are enabled with the same multicast address for the purpose
of efficient group communications. All groups within a sector
have unique names.
Endpoint Endpoint
Endpoint (EP) is a term used to describe a web server or client in Endpoint (EP) is a term used to describe a web server or client in
[RFC7252]. In the context of this specification an endpoint is [RFC7252]. In the context of this specification an endpoint is
used to describe a web server that registers resources to the used to describe a web server that registers resources to the
Resource Directory. An endpoint is identified by its endpoint Resource Directory. An endpoint is identified by its endpoint
name, which is included during registration, and has a unique name name, which is included during registration, and has a unique name
within the associated sector of the registration. within the associated sector of the registration.
Registration Base URI Registration Base URI
The Base URI of a Registration is a URI that typically gives The Base URI of a Registration is a URI that typically gives
skipping to change at page 6, line 16 skipping to change at page 6, line 5
context is made explicit in serialized links as the "anchor=" context is made explicit in serialized links as the "anchor="
attribute. attribute.
This use of the term Context is consistent with [RFC8288]'s use of This use of the term Context is consistent with [RFC8288]'s use of
the term. the term.
Directory Resource Directory Resource
A resource in the Resource Directory (RD) containing registration A resource in the Resource Directory (RD) containing registration
resources. resources.
Group Resource
A resource in the RD containing registration resources of the
Endpoints that form a group.
Registration Resource Registration Resource
A resource in the RD that contains information about an Endpoint A resource in the RD that contains information about an Endpoint
and its links. and its links.
Commissioning Tool Commissioning Tool
Commissioning Tool (CT) is a device that assists during the Commissioning Tool (CT) is a device that assists during the
installation of the network by assigning values to parameters, installation of the network by assigning values to parameters,
naming endpoints and groups, or adapting the installation to the naming endpoints and groups, or adapting the installation to the
needs of the applications. needs of the applications.
skipping to change at page 7, line 41 skipping to change at page 7, line 23
3.2. Architecture 3.2. Architecture
The resource directory architecture is illustrated in Figure 1. A The resource directory architecture is illustrated in Figure 1. A
Resource Directory (RD) is used as a repository for Web Links Resource Directory (RD) is used as a repository for Web Links
[RFC5988] describing resources hosted on other web servers, also [RFC5988] describing resources hosted on other web servers, also
called endpoints (EP). An endpoint is a web server associated with a called endpoints (EP). An endpoint is a web server associated with a
scheme, IP address and port. A physical node may host one or more scheme, IP address and port. A physical node may host one or more
endpoints. The RD implements a set of REST interfaces for endpoints endpoints. The RD implements a set of REST interfaces for endpoints
to register and maintain sets of Web Links (called resource directory to register and maintain sets of Web Links (called resource directory
registration entries), and for endpoints to lookup resources from the registration entries), and for endpoints to lookup resources from the
RD or maintain groups. An RD can be logically segmented by the use RD. An RD can be logically segmented by the use of Sectors. This
of Sectors. The set of endpoints grouped for group communication can
be defined by the RD or configured by a Commissioning Tool. This
information hierarchy is shown in Figure 2. information hierarchy is shown in Figure 2.
A mechanism to discover an RD using CoRE Link Format [RFC6690] is A mechanism to discover an RD using CoRE Link Format [RFC6690] is
defined. defined.
Registration entries in the RD are soft state and need to be Registration entries in the RD are soft state and need to be
periodically refreshed. periodically refreshed.
An endpoint uses specific interfaces to register, update and remove a An endpoint uses specific interfaces to register, update and remove a
resource directory registration entry. It is also possible for an RD resource directory registration entry. It is also possible for an RD
skipping to change at page 8, line 18 skipping to change at page 8, line 5
registration entries. registration entries.
At the first registration of a set of entries, a "registration At the first registration of a set of entries, a "registration
resource" is created, the location of which is returned to the resource" is created, the location of which is returned to the
registering endpoint. The registering endpoint uses this registering endpoint. The registering endpoint uses this
registration resource to manage the contents of registration entries. registration resource to manage the contents of registration entries.
A lookup interface for discovering any of the Web Links held in the A lookup interface for discovering any of the Web Links held in the
RD is provided using the CoRE Link Format. RD is provided using the CoRE Link Format.
Registration Lookup, Group Registration Lookup
Interface Interfaces Interface Interface
+----+ | | +----+ | |
| EP |---- | | | EP |---- | |
+----+ ---- | | +----+ ---- | |
--|- +------+ | --|- +------+ |
+----+ | ----| | | +--------+ +----+ | ----| | | +--------+
| EP | ---------|-----| RD |----|-----| Client | | EP | ---------|-----| RD |----|-----| Client |
+----+ | ----| | | +--------+ +----+ | ----| | | +--------+
--|- +------+ | --|- +------+ |
+----+ ---- | | +----+ ---- | |
| EP |---- | | | EP |---- | |
+----+ +----+
Figure 1: The resource directory architecture. Figure 1: The resource directory architecture.
+------------+ +------------+
| Group | <-- Name, Scheme, IP, Port
+------------+
|
|
+------------+
| Endpoint | <-- Name, Scheme, IP, Port | Endpoint | <-- Name, Scheme, IP, Port
+------------+ +------------+
| |
| |
+------------+ +------------+
| Resource | <-- Target, Parameters | Resource | <-- Target, Parameters
+------------+ +------------+
Figure 2: The resource directory information hierarchy. Figure 2: The resource directory information hierarchy.
skipping to change at page 12, line 5 skipping to change at page 11, line 5
(e.g. _what_ is hosted), and is the topic of all target (e.g. _what_ is hosted), and is the topic of all target
attributes. attributes.
In link-format serialization, it is expressed between angular In link-format serialization, it is expressed between angular
brackets, and sometimes called the "href". brackets, and sometimes called the "href".
o Other target attributes (e.g. resource type (rt), interface (if), o Other target attributes (e.g. resource type (rt), interface (if),
or content-type (ct)). These provide additional information about or content-type (ct)). These provide additional information about
the target URI. the target URI.
+----------------------+ 1 ooooooo +----------------------+
| resource-directory | +--o href o | resource-directory |
+----------------------+ | ooooooo +----------------------+
| 1 | | 1
| oooooooooo 0-1 | 1 oooooo |
| o base o---+ | +------o gp o |
| ooooooooooo | | | oooooo |
| | | | |
//////\\\\ 0+ +--------+ 0-1 ooooo //////\\\\
< contains >----------------| group |------o d o < contains >
\\\\\///// +--------+ ooooo \\\\\/////
| | 0+ |
0+ | | 0+ |
ooooooo 1 +---------------+ 1+ ///////\\\\\\ ooooooo 1 +---------------+
o base o-------| registration |---------< composed of > o base o-------| registration |
ooooooo +---------------+ \\\\\\\////// ooooooo +---------------+
| | 1 | | 1
| +--------------+ | +--------------+
oooooooo 1 | | oooooooo 1 | |
o href o----+ /////\\\\ o href o----+ /////\\\\
oooooooo | < contains > oooooooo | < contains >
| \\\\\///// | \\\\\/////
oooooooo 1 | | oooooooo 1 | |
o ep o----+ | 0+ o ep o----+ | 0+
oooooooo | +------------------+ oooooooo | +------------------+
| | link | | | link |
skipping to change at page 13, line 4 skipping to change at page 12, line 4
ooooooooooo | 1 ooooooooo ooooooooooo | 1 ooooooooo
+----o context o +----o context o
ooooooooo ooooooooo
Figure 4: E-R Model of the content of the Resource Directory Figure 4: E-R Model of the content of the Resource Directory
The model shown in Figure 4 models the contents of the resource The model shown in Figure 4 models the contents of the resource
directory which contains in addition to /.well-known/core: directory which contains in addition to /.well-known/core:
o 0 to n Registration (entries) of endpoints, o 0 to n Registration (entries) of endpoints,
o 0 or more Groups A registration is associated with one endpoint. A registration
defines a set of links as defined for /.well-known/core. A
A Group has: Registration has six types of attributes:
o a group name ("gp"),
o optionally a sector (abbreviated "d" for historical reasons),
o a group resource location inside the RD ("href"),
o zero or one multicast addresses expressed as a base URI ("base"),
o and is composed of zero or more registrations (endpoints).
A registration is associated with one endpoint. A registration can
be part of 0 or more Groups . A registration defines a set of links
as defined for /.well-known/core. A Registration has six types of
attributes:
o a unique endpoint name ("ep") within a sector o a unique endpoint name ("ep") within a sector
o a Registration Base URI ("base", a URI typically describing the o a Registration Base URI ("base", a URI typically describing the
scheme://authority part) scheme://authority part)
o a lifetime ("lt"), o a lifetime ("lt"),
o a registration resource location inside the RD ("href"), o a registration resource location inside the RD ("href"),
o optionally a sector ("d") o optionally a sector ("d")
o optional additional endpoint attributes (from Section 10.3) o optional additional endpoint attributes (from Section 9.3)
The cardinality of "base" is currently 1; future documents are The cardinality of "base" is currently 1; future documents are
invited to extend the RD specification to support multiple values invited to extend the RD specification to support multiple values
(e.g. [I-D.silverajan-core-coap-protocol-negotiation]). Its value (e.g. [I-D.silverajan-core-coap-protocol-negotiation]). Its value
is used as a Base URI when resolving URIs in the links contained in is used as a Base URI when resolving URIs in the links contained in
the endpoint. the endpoint.
Links are modelled as they are in Figure 3. Links are modelled as they are in Figure 3.
3.4. Use Case: Cellular M2M 3.4. Use Case: Cellular M2M
skipping to change at page 15, line 29 skipping to change at page 14, line 15
External catalogues that are represented in other formats may be External catalogues that are represented in other formats may be
converted to common web linking formats for storage and access by converted to common web linking formats for storage and access by
Resource Directories. Since it is common practice for these to be Resource Directories. Since it is common practice for these to be
URN encoded, simple and lossless structural transforms should URN encoded, simple and lossless structural transforms should
generally be sufficient to store external metadata in Resource generally be sufficient to store external metadata in Resource
Directories. Directories.
The additional features of Resource Directory allow sectors to be The additional features of Resource Directory allow sectors to be
defined to enable access to a particular set of resources from defined to enable access to a particular set of resources from
particular applications. This provides isolation and protection of particular applications. This provides isolation and protection of
sensitive data when needed. Groups may be defined to support sensitive data when needed. Application groups with multicast
efficient data transport. addresses may be defined to support efficient data transport.
4. Finding a Resource Directory 4. Finding a Resource Directory
A (re-)starting device may want to find one or more resource A (re-)starting device may want to find one or more resource
directories for discovery purposes. directories for discovery purposes.
The device may be pre-configured to exercise specific mechanisms for The device may be pre-configured to exercise specific mechanisms for
finding the resource directory: finding the resource directory:
1. It may be configured with a specific IP address for the RD. That 1. It may be configured with a specific IP address for the RD. That
skipping to change at page 19, line 43 skipping to change at page 17, line 51
This section defines discovery of the RD and its URIs using the well- This section defines discovery of the RD and its URIs using the well-
known interface of the CoRE Link Format [RFC6690]. A complete set of known interface of the CoRE Link Format [RFC6690]. A complete set of
RD discovery methods is described in Section 4. RD discovery methods is described in Section 4.
Discovery of the RD registration URI path is performed by sending Discovery of the RD registration URI path is performed by sending
either a multicast or unicast GET request to "/.well-known/core" and either a multicast or unicast GET request to "/.well-known/core" and
including a Resource Type (rt) parameter [RFC6690] with the value including a Resource Type (rt) parameter [RFC6690] with the value
"core.rd" in the query string. Likewise, a Resource Type parameter "core.rd" in the query string. Likewise, a Resource Type parameter
value of "core.rd-lookup*" is used to discover the URIs for RD Lookup value of "core.rd-lookup*" is used to discover the URIs for RD Lookup
operations, core.rd* is used to discover all URI paths for RD operations, core.rd* is used to discover all URI paths for RD
operations, and "core.rd-group" is used to discover the URI path for operations. Upon success, the response will contain a payload with a
RD Group operations. Upon success, the response will contain a link format entry for each RD function discovered, indicating the URI
payload with a link format entry for each RD function discovered, of the RD function returned and the corresponding Resource Type.
indicating the URI of the RD function returned and the corresponding When performing multicast discovery, the multicast IP address used
Resource Type. When performing multicast discovery, the multicast IP will depend on the scope required and the multicast capabilities of
address used will depend on the scope required and the multicast the network (see Section 9.5.
capabilities of the network (see Section 10.5.
A Resource Directory MAY provide hints about the content-formats it A Resource Directory MAY provide hints about the content-formats it
supports in the links it exposes or registers, using the "ct" link supports in the links it exposes or registers, using the "ct" link
attribute, as shown in the example below. Clients MAY use these attribute, as shown in the example below. Clients MAY use these
hints to select alternate content-formats for interaction with the hints to select alternate content-formats for interaction with the
Resource Directory. Resource Directory.
HTTP does not support multicast and consequently only unicast HTTP does not support multicast and consequently only unicast
discovery can be supported using HTTP. The well-known entry points discovery can be supported using HTTP. The well-known entry points
SHOULD be provided to enable unicast discovery. SHOULD be provided to enable unicast discovery.
skipping to change at page 20, line 39 skipping to change at page 18, line 46
Interaction: EP and Client -> RD Interaction: EP and Client -> RD
Method: GET Method: GET
URI Template: /.well-known/core{?rt} URI Template: /.well-known/core{?rt}
URI Template Variables: URI Template Variables:
rt := Resource Type. SHOULD contain one of the values "core.rd", rt := Resource Type. SHOULD contain one of the values "core.rd",
"core.rd-lookup*", "core.rd-lookup-res", "core.rd-lookup-ep", "core.rd-lookup*", "core.rd-lookup-res", "core.rd-lookup-ep",
"core.rd-lookup-gp", "core.rd-group" or "core.rd*" or "core.rd*"
Content-Format: application/link-format (if any) Content-Format: application/link-format (if any)
Content-Format: application/link-format+json (if any) Content-Format: application/link-format+json (if any)
Content-Format: application/link-format+cbor (if any) Content-Format: application/link-format+cbor (if any)
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.05 "Content" or 200 "OK" with an application/link-format, Success: 2.05 "Content" or 200 "OK" with an application/link-format,
application/link-format+json, or application/link-format+cbor application/link-format+json, or application/link-format+cbor
payload containing one or more matching entries for the RD payload containing one or more matching entries for the RD
resource. resource.
Failure: 4.00 "Bad Request" or 400 "Bad Request" is returned in case Failure: 4.00 "Bad Request" or 400 "Bad Request" is returned in case
skipping to change at page 21, line 26 skipping to change at page 19, line 32
this example, is /rd, and that the content-format delivered by the this example, is /rd, and that the content-format delivered by the
server hosting the resource is application/link-format (ct=40). Note server hosting the resource is application/link-format (ct=40). Note
that it is up to the RD to choose its RD locations. that it is up to the RD to choose its RD locations.
Req: GET coap://[MCD1]/.well-known/core?rt=core.rd* Req: GET coap://[MCD1]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
</rd>;rt="core.rd";ct=40, </rd>;rt="core.rd";ct=40,
</rd-lookup/ep>;rt="core.rd-lookup-ep";ct=40, </rd-lookup/ep>;rt="core.rd-lookup-ep";ct=40,
</rd-lookup/res>;rt="core.rd-lookup-res";ct=40, </rd-lookup/res>;rt="core.rd-lookup-res";ct=40,
</rd-lookup/gp>;rt="core.rd-lookup-gp";ct=40,
</rd-group>;rt="core.rd-group";ct=40
Figure 6: Example discovery exchange Figure 6: Example discovery exchange
The following example shows the way of indicating that a client may The following example shows the way of indicating that a client may
request alternate content-formats. The Content-Format code attribute request alternate content-formats. The Content-Format code attribute
"ct" MAY include a space-separated sequence of Content-Format codes "ct" MAY include a space-separated sequence of Content-Format codes
as specified in Section 7.2.1 of [RFC7252], indicating that multiple as specified in Section 7.2.1 of [RFC7252], indicating that multiple
content-formats are available. The example below shows the required content-formats are available. The example below shows the required
Content-Format 40 (application/link-format) indicated as well as the Content-Format 40 (application/link-format) indicated as well as the
CBOR and JSON representation of link format. The RD resource CBOR and JSON representation of link format. The RD resource
locations /rd, /rd-lookup, and /rd-group are example values. The locations /rd, and /rd-lookup are example values. The server in this
server in this example also indicates that it is capable of providing example also indicates that it is capable of providing observation on
observation on resource lookups. resource lookups.
[ The RFC editor is asked to replace these and later occurrences of [ The RFC editor is asked to replace these and later occurrences of
MCD1, TBD64 and TBD504 with the assigned IPv6 site-local address for MCD1, TBD64 and TBD504 with the assigned IPv6 site-local address for
"all CoRE Resource Directories" and the numeric ID values assigned by "all CoRE Resource Directories" and the numeric ID values assigned by
IANA to application/link-format+cbor and application/link- IANA to application/link-format+cbor and application/link-
format+json, respectively, as they are defined in I-D.ietf-core- format+json, respectively, as they are defined in I-D.ietf-core-
links-json. ] links-json. ]
Req: GET coap://[MCD1]/.well-known/core?rt=core.rd* Req: GET coap://[MCD1]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
</rd>;rt="core.rd";ct="40 65225", </rd>;rt="core.rd";ct="40 65225",
</rd-lookup/res>;rt="core.rd-lookup-res";ct="40 TBD64 TBD504";obs, </rd-lookup/res>;rt="core.rd-lookup-res";ct="40 TBD64 TBD504";obs,
</rd-lookup/ep>;rt="core.rd-lookup-ep";ct="40 TBD64 TBD504", </rd-lookup/ep>;rt="core.rd-lookup-ep";ct="40 TBD64 TBD504",
</rd-lookup/gp>;rt="core.rd-lookup-gp";ct=40 TBD64 TBD504",
</rd-group>;rt="core.rd-group";ct="40 TBD64 TBD504"
From a management and maintenance perspective, it is necessary to From a management and maintenance perspective, it is necessary to
identify the components that constitute the RD server. The identify the components that constitute the RD server. The
identification refers to information about for example client-server identification refers to information about for example client-server
incompatibilities, supported features, required updates and other incompatibilities, supported features, required updates and other
aspects. The URI discovery address, a described in section 4 of aspects. The URI discovery address, a described in section 4 of
[RFC6690] can be used to find the identification. [RFC6690] can be used to find the identification.
It would typically be stored in an implementation information link It would typically be stored in an implementation information link
(as described in [I-D.bormann-t2trg-rel-impl]): (as described in [I-D.bormann-t2trg-rel-impl]):
skipping to change at page 22, line 47 skipping to change at page 20, line 45
After discovering the location of an RD, a registrant-ep or CT MAY After discovering the location of an RD, a registrant-ep or CT MAY
register the resources of the registrant-ep using the registration register the resources of the registrant-ep using the registration
interface. This interface accepts a POST from an endpoint containing interface. This interface accepts a POST from an endpoint containing
the list of resources to be added to the directory as the message the list of resources to be added to the directory as the message
payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format payload in the CoRE Link Format [RFC6690], JSON CoRE Link Format
(application/link-format+json), or CBOR CoRE Link Format (application/link-format+json), or CBOR CoRE Link Format
(application/link-format+cbor) [I-D.ietf-core-links-json], along with (application/link-format+cbor) [I-D.ietf-core-links-json], along with
query parameters indicating the name of the endpoint, and optionally query parameters indicating the name of the endpoint, and optionally
the sector, lifetime and base URI of the registration. It is the sector, lifetime and base URI of the registration. It is
expected that other specifications will define further parameters expected that other specifications will define further parameters
(see Section 10.3). The RD then creates a new registration resource (see Section 9.3). The RD then creates a new registration resource
in the RD and returns its location. The receiving endpoint MUST use in the RD and returns its location. The receiving endpoint MUST use
that location when refreshing registrations using this interface. that location when refreshing registrations using this interface.
Registration resources in the RD are kept active for the period Registration resources in the RD are kept active for the period
indicated by the lifetime parameter. The creating endpoint is indicated by the lifetime parameter. The creating endpoint is
responsible for refreshing the registration resource within this responsible for refreshing the registration resource within this
period using either the registration or update interface. The period using either the registration or update interface. The
registration interface MUST be implemented to be idempotent, so that registration interface MUST be implemented to be idempotent, so that
registering twice with the same endpoint parameters ep and d (sector) registering twice with the same endpoint parameters ep and d (sector)
does not create multiple registration resources. does not create multiple registration resources.
skipping to change at page 25, line 22 skipping to change at page 23, line 22
Endpoints that register with a base that contains a path Endpoints that register with a base that contains a path
component can not meaningfully use [RFC6690] Link Format due to component can not meaningfully use [RFC6690] Link Format due to
its prevalence of the Origin concept in relative reference its prevalence of the Origin concept in relative reference
resolution; they can submit payloads for interpretation as resolution; they can submit payloads for interpretation as
Modernized Link Format. Typically, links submitted by such an Modernized Link Format. Typically, links submitted by such an
endpoint are of the "path-noscheme" (starts with a path not endpoint are of the "path-noscheme" (starts with a path not
preceded by a slash, precisely defined in [RFC3986] preceded by a slash, precisely defined in [RFC3986]
Section 3.3) form. Section 3.3) form.
extra-attrs := Additional registration attributes (optional). extra-attrs := Additional registration attributes (optional).
The endpoint can pass any parameter registered at Section 10.3 The endpoint can pass any parameter registered at Section 9.3
to the directory. If the RD is aware of the parameter's to the directory. If the RD is aware of the parameter's
specified semantics, it processes it accordingly. Otherwise, specified semantics, it processes it accordingly. Otherwise,
it MUST store the unknown key and its value(s) as an endpoint it MUST store the unknown key and its value(s) as an endpoint
attribute for further lookup. attribute for further lookup.
Content-Format: application/link-format Content-Format: application/link-format
Content-Format: application/link-format+json Content-Format: application/link-format+json
Content-Format: application/link-format+cbor Content-Format: application/link-format+cbor
skipping to change at page 30, line 7 skipping to change at page 28, line 7
scheme, IP address and port of the URI of the registered device is scheme, IP address and port of the URI of the registered device is
the value of the "base" parameter of the registration described in the value of the "base" parameter of the registration described in
Section 5.3. Section 5.3.
It should be noted that the value of the "base" parameter applies to It should be noted that the value of the "base" parameter applies to
all the links of the registration and has consequences for the anchor all the links of the registration and has consequences for the anchor
value of the individual links as exemplified in Appendix B. An value of the individual links as exemplified in Appendix B. An
eventual (currently non-existing) "base" attribute of the link is not eventual (currently non-existing) "base" attribute of the link is not
affected by the value of "base" parameter in the registration. affected by the value of "base" parameter in the registration.
6. RD Groups 5.3.3. RD-Groups
This section defines the REST API for the creation, management, and
lookup of endpoints for group operations. Similar to endpoint
registration entries in the RD, groups may be created or removed.
However unlike an endpoint entry, a group entry consists of a list of
endpoints and does not have a lifetime associated with it. To make
use of multicast requests with CoAP, a group MAY have a multicast
address associated with it, and should share a common set of
resources.
6.1. Register a Group
To create a group, a commissioning tool (CT) used to configure
groups, makes a request to the RD indicating the name of the group to
create (or update), optionally the sector the group belongs to, and
optionally the multicast address of the group. This specification
does not require that the endpoints belong to the same sector as the
group, but a Resource Directory implementation can impose
requirements on the sectors of groups and endpoints depending on its
configuration.
The registration message is a list of links to registration resources
of the endpoints that belong to that group. The CT can use any URI
reference discovered using endpoint lookup from the same server or
obtained by registering an endpoint using third party registration
and enter it into a group.
The commissioning tool SHOULD not send any target attributes with the
links to the registration resources, and the resource directory
SHOULD reject registrations that contain links with unprocessable
attributes.
Configuration of the endpoints themselves is out of scope of this
specification. Such an interface for managing the group membership
of an endpoint has been defined in [RFC7390].
The registration request interface is specified as follows:
Interaction: CT -> RD
Method: POST
URI Template: {+rd-group}{?gp,d,base}
URI Template Variables:
rd-group := RD Group URI (mandatory). This is the location of
the RD Group REST API.
gp := Group Name (mandatory). The name of the group to be
created or replaced, unique within that sector. The maximum
length of this parameter is 63 bytes.
d := Sector (optional). The sector to which this group belongs.
The maximum length of this parameter is 63 bytes. When this
parameter is not present, the RD MAY associate the group with a
configured default sector or leave it empty.
base := Group Base URI (optional). This parameter sets the
scheme, address and port of the multicast address associated
with the group. When base is used, scheme and host are
mandatory and port parameter is optional.
Content-Format: application/link-format
Content-Format: application/link-format+json
Content-Format: application/link-format+cbor
The following response codes are defined for this interface:
Success: 2.01 "Created" or 201 "Created". The Location header or
Location-Path option MUST be returned in response to a successful
group CREATE operation. This location MUST be a stable identifier
generated by the RD as it is used for delete operations of the
group resource.
As with the Registration operation, the location MUST NOT have a The RD-Groups usage pattern allows announcing application groups
query or fragment component. inside a Resource Directory.
Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed Groups are represented by endpoint registrations. Their base address
request. is a multicast address, and they SHOULD be entered with the endpoint
type "core.rd-group". The endpoint name can also be referred to as a
group name in this context.
Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". The registration is inserted into the RD by a Commissioning Tool,
Service could not perform the operation. which might also be known as a group manager here. It performs third
party registration and registration updates.
HTTP support: YES The links it registers SHOULD be available on all members that join
the group. Depending on the application, members that lack some
resource MAY be permissible if requests to them fail gracefully.
The following example shows an EP registering a group with the name The following example shows a CT registering a group with the name
"lights" which has two endpoints. The RD group path /rd-group is an "lights" which provides two resources. The directory resource path
example RD location discovered in a request similar to Figure 6. /rd is an example RD location discovered in a request similar to
Figure 6.
Req: POST coap://rd.example.com/rd-group?gp=lights Req: POST coap://rd.example.com/rd?ep=lights&et=core.rd-group
&base=coap://[ff35:30:2001:db8::1] &base=coap://[ff35:30:2001:db8::1]
Content-Format: 40 Content-Format: 40
Payload: Payload:
</rd/4521>, </light>;rt="light";if="core.a",
</rd/4520> </color-temperature>;if="core.p";u="K"
Res: 2.01 Created Res: 2.01 Created
Location-Path: /rd-group/12 Location-Path: /rd/12
A relative href value denotes the path to the registration resource
of the Endpoint. When pointing to a registration resource on a
different RD, the href value is a URI.
6.2. Group Removal
A group can be removed simply by sending a removal message to the
location of the group registration resource which was returned when
initially registering the group. Removing a group MUST NOT remove
the endpoints of the group from the RD.
The removal request interface is specified as follows:
Interaction: CT -> RD
Method: DELETE
URI Template: {+location}
URI Template Variables:
location := This is the path of the group resource returned by
the RD as a result of a successful group registration.
The following responses codes are defined for this interface:
Success: 2.02 "Deleted" or 204 "No Content" upon successful deletion
Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request.
Failure: 4.04 "Not Found" or 404 "Not Found". Group does not exist.
Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
Service could not perform the operation.
HTTP support: YES
The following examples shows successful removal of the group from the
RD with the example location value /rd-group/12.
Req: DELETE /rd-group/12 In this example, the group manager can easily permit devices that
have no writable color-temperature to join, as they would still
respond to brightness changing commands. Had the group instead
contained a single resource that sets brightness and color
temperature atomically, endpoints would need to support both
properties.
Res: 2.02 Deleted The resources of a group can be looked up like any other resource,
and the group registrations (along with any additional registration
parameters) can be looked up using the endpoint lookup interface.
7. RD Lookup 6. RD Lookup
To discover the resources registered with the RD, a lookup interface To discover the resources registered with the RD, a lookup interface
must be provided. This lookup interface is defined as a default, and must be provided. This lookup interface is defined as a default, and
it is assumed that RDs may also support lookups to return resource it is assumed that RDs may also support lookups to return resource
descriptions in alternative formats (e.g. Atom or HTML Link) or descriptions in alternative formats (e.g. Atom or HTML Link) or
using more advanced interfaces (e.g. supporting context or semantic using more advanced interfaces (e.g. supporting context or semantic
based lookup). based lookup).
RD Lookup allows lookups for groups, endpoints and resources using RD Lookup allows lookups for endpoints and resources using attributes
attributes defined in this document and for use with the CoRE Link defined in this document and for use with the CoRE Link Format. The
Format. The result of a lookup request is the list of links (if any) result of a lookup request is the list of links (if any)
corresponding to the type of lookup. Thus, a group lookup MUST corresponding to the type of lookup. Thus, an endpoint lookup MUST
return a list of groups, an endpoint lookup MUST return a list of return a list of endpoints and a resource lookup MUST return a list
endpoints and a resource lookup MUST return a list of links to of links to resources.
resources.
The lookup type is selected by a URI endpoint, which is indicated by The lookup type is selected by a URI endpoint, which is indicated by
a Resource Type as per Table 1 below: a Resource Type as per Table 1 below:
+-------------+--------------------+-----------+ +-------------+--------------------+-----------+
| Lookup Type | Resource Type | Mandatory | | Lookup Type | Resource Type | Mandatory |
+-------------+--------------------+-----------+ +-------------+--------------------+-----------+
| Resource | core.rd-lookup-res | Mandatory | | Resource | core.rd-lookup-res | Mandatory |
| Endpoint | core.rd-lookup-ep | Mandatory | | Endpoint | core.rd-lookup-ep | Mandatory |
| Group | core.rd-lookup-gp | Optional |
+-------------+--------------------+-----------+ +-------------+--------------------+-----------+
Table 1: Lookup Types Table 1: Lookup Types
7.1. Resource lookup 6.1. Resource lookup
Resource lookup results in links that are semantically equivalent to Resource lookup results in links that are semantically equivalent to
the links submitted to the RD. The links and link parameters the links submitted to the RD. The links and link parameters
returned by the lookup are equal to the submitted ones, except that returned by the lookup are equal to the submitted ones, except that
the target and anchor references are fully resolved. the target and anchor references are fully resolved.
Links that did not have an anchor attribute are therefore returned Links that did not have an anchor attribute are therefore returned
with the base URI of the registration as the anchor. Links of which with the base URI of the registration as the anchor. Links of which
href or anchor was submitted as a (full) URI are returned with these href or anchor was submitted as a (full) URI are returned with these
attributes unmodified. attributes unmodified.
Above rules allow the client to interpret the response as links Above rules allow the client to interpret the response as links
without any further knowledge of the storage conventions of the RD. without any further knowledge of the storage conventions of the RD.
The Resource Directory MAY replace the registration base URIs with a The Resource Directory MAY replace the registration base URIs with a
configured intermediate proxy, e.g. in the case of an HTTP lookup configured intermediate proxy, e.g. in the case of an HTTP lookup
interface for CoAP endpoints. interface for CoAP endpoints.
7.2. Lookup filtering 6.2. Lookup filtering
Using the Accept Option, the requester can control whether the Using the Accept Option, the requester can control whether the
returned list is returned in CoRE Link Format ("application/link- returned list is returned in CoRE Link Format ("application/link-
format", default) or its alternate content-formats ("application/ format", default) or its alternate content-formats ("application/
link-format+json" or "application/link-format+cbor"). link-format+json" or "application/link-format+cbor").
The page and count parameters are used to obtain lookup results in The page and count parameters are used to obtain lookup results in
specified increments using pagination, where count specifies how many specified increments using pagination, where count specifies how many
links to return and page specifies which subset of links organized in links to return and page specifies which subset of links organized in
sequential pages, each containing 'count' links, starting with link sequential pages, each containing 'count' links, starting with link
skipping to change at page 34, line 36 skipping to change at page 30, line 30
Multiple search criteria MAY be included in a lookup. All included Multiple search criteria MAY be included in a lookup. All included
criteria MUST match for a link to be returned. The Resource criteria MUST match for a link to be returned. The Resource
Directory MUST support matching with multiple search criteria. Directory MUST support matching with multiple search criteria.
A link matches a search criterion if it has an attribute of the same A link matches a search criterion if it has an attribute of the same
name and the same value, allowing for a trailing "*" wildcard name and the same value, allowing for a trailing "*" wildcard
operator as in Section 4.1 of [RFC6690]. Attributes that are defined operator as in Section 4.1 of [RFC6690]. Attributes that are defined
as "link-type" match if the search value matches any of their values as "link-type" match if the search value matches any of their values
(see Section 4.1 of [RFC6690]; e.g. "?if=core.s" matches ";if="abc (see Section 4.1 of [RFC6690]; e.g. "?if=core.s" matches ";if="abc
core.s";"). A link also matches a search criterion if the link that core.s";"). A resource link also matches a search criterion if its
would be produced for any of its containing entities would match the endpoint would match the criterion, and vice versa, an endpoint link
criterion, or an entity contained in it would: A search criterion matches a search criterion if any of its resource links matches it.
matches an endpoint if it matches the endpoint itself, any of the
groups it is contained in or any resource it contains. A search
criterion matches a resource if it matches the resource itself, the
resource's endpoint, or any of the endpoint's groups.
Note that "href" is a valid search criterion and matches target Note that "href" is a valid search criterion and matches target
references. Like all search criteria, on a resource lookup it can references. Like all search criteria, on a resource lookup it can
match the target reference of the resource link itself, but also the match the target reference of the resource link itself, but also the
registration resource of the endpoint that registered it, or any registration resource of the endpoint that registered it. Queries
group resource that endpoint is contained in. Queries for resource for resource link targets MUST be in URI form (i.e. not relative
link targets MUST be in URI form (i.e. not relative references) and references) and are matched against a resolved link target. Queries
are matched against a resolved link target. Queries for groups and for endpoints SHOULD be expressed in path-absolute form if possible
endpoints SHOULD be expressed in path-absolute form if possible and and MUST be expressed in URI form otherwise; the RD SHOULD recognize
MUST be expressed in URI form otherwise; the RD SHOULD recognize
either. either.
Endpoints that are interested in a lookup result repeatedly or Endpoints that are interested in a lookup result repeatedly or
continuously can use mechanisms like ETag caching, resource continuously can use mechanisms like ETag caching, resource
observation ([RFC7641]), or any future mechanism that might allow observation ([RFC7641]), or any future mechanism that might allow
more efficient observations of collections. These are advertised, more efficient observations of collections. These are advertised,
detected and used according to their own specifications and can be detected and used according to their own specifications and can be
used with the lookup interface as with any other resource. used with the lookup interface as with any other resource.
When resource observation is used, every time the set of matching When resource observation is used, every time the set of matching
skipping to change at page 36, line 27 skipping to change at page 32, line 17
Failure: No error response to a multicast request. Failure: No error response to a multicast request.
Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request. request.
Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable". Failure: 5.03 "Service Unavailable" or 503 "Service Unavailable".
Service could not perform the operation. Service could not perform the operation.
HTTP support: YES HTTP support: YES
The group and endpoint lookup return registration resources which can The endpoint lookup returns registration resources which can only be
only be manipulated by the registering endpoint. Examples of group manipulated by the registering endpoint. Examples of endpoint lookup
and endpoint lookup belong to the management aspects of the RD and belong to the management aspects of the RD and are shown in
are shown in Appendix A.5. The resource lookup examples are shown in Appendix A.5. The resource lookup examples are shown in this
this section. section.
7.3. Resource lookup examples 6.3. Resource lookup examples
The examples in this section assume the existence of CoAP hosts with The examples in this section assume the existence of CoAP hosts with
a default CoAP port 61616. HTTP hosts are possible and do not change a default CoAP port 61616. HTTP hosts are possible and do not change
the nature of the examples. the nature of the examples.
The following example shows a client performing a resource lookup The following example shows a client performing a resource lookup
with the example resource look-up locations discovered in Figure 6: with the example resource look-up locations discovered in Figure 6:
Req: GET /rd-lookup/res?rt=temperature Req: GET /rd-lookup/res?rt=temperature
skipping to change at page 39, line 28 skipping to change at page 35, line 28
anchor="coap://sensor2.example.com", anchor="coap://sensor2.example.com",
<coap://sensor2.example.com/sensors/temp>;rt="temperature-c"; <coap://sensor2.example.com/sensors/temp>;rt="temperature-c";
if="sensor"; anchor="coap://sensor2.example.com", if="sensor"; anchor="coap://sensor2.example.com",
<coap://sensor2.example.com/sensors/light>;rt="light-lux"; <coap://sensor2.example.com/sensors/light>;rt="light-lux";
if="sensor"; anchor="coap://sensor2.example.com", if="sensor"; anchor="coap://sensor2.example.com",
<http://www.example.com/sensors/t123>;rel="describedby"; <http://www.example.com/sensors/t123>;rel="describedby";
anchor="coap://sensor2.example.com/sensors/temp", anchor="coap://sensor2.example.com/sensors/temp",
<coap://sensor2.example.com/t>;rel="alternate"; <coap://sensor2.example.com/t>;rel="alternate";
anchor="coap://sensor2.example.com/sensors/temp" anchor="coap://sensor2.example.com/sensors/temp"
8. Security policies The following example shows a client performing a lookup of all
resources of all endpoints (groups) with et=core.rd-group.
Req: GET /rd-lookup/res?et=core.rd-group
<coap://[ff35:30:2001:db8::1]/light>;rt="light";if="core.a";
et="core.rd-group";anchor="coap://[ff35:30:2001:db8::1]",
<coap://[ff35:30:2001:db8::1]/color-temperature>;if="core.p";u="K";
et="core.rd-group";
anchor="coap://[ff35:30:2001:db8::1]"
7. Security policies
The Resource Directory (RD) provides assistance to applications The Resource Directory (RD) provides assistance to applications
situated on a selection of nodes to discover endpoints on connected situated on a selection of nodes to discover endpoints on connected
nodes. This section discusses different security aspects of nodes. This section discusses different security aspects of
accessing the RD. accessing the RD.
The contents of the RD are inserted in two ways: The contents of the RD are inserted in two ways:
1. The node hosting the discoverable endpoint fills the RD with the 1. The node hosting the discoverable endpoint fills the RD with the
contents of /.well-known/core by: contents of /.well-known/core by:
skipping to change at page 40, line 36 skipping to change at page 36, line 46
or can be more fine-grained, including a subset of registration or can be more fine-grained, including a subset of registration
parameter values. * A given endpoint that registers itself, needs to parameter values. * A given endpoint that registers itself, needs to
proof its possession of its unique (endpoint name, sector) value proof its possession of its unique (endpoint name, sector) value
pair. Alternatively, the AS can authorize the endpoint to register pair. Alternatively, the AS can authorize the endpoint to register
with an (endpoint name, sector) value pair assigned by the AS. * A with an (endpoint name, sector) value pair assigned by the AS. * A
separate document needs to specify these aspects to ensure separate document needs to specify these aspects to ensure
interoperability between registering nodes and RD. The subsections interoperability between registering nodes and RD. The subsections
below give some hints how to handle a subset of the different below give some hints how to handle a subset of the different
aspects. aspects.
8.1. Secure RD discovery 7.1. Secure RD discovery
The Resource Server (RS) discussed in [I-D.ietf-ace-oauth-authz] is The Resource Server (RS) discussed in [I-D.ietf-ace-oauth-authz] is
equated to the RD. The client (C) needs to discover the RD as equated to the RD. The client (C) needs to discover the RD as
discussed in Section 4. C can discover the related AS by sending a discussed in Section 4. C can discover the related AS by sending a
request to the RD. The RD denies the request by sending the address request to the RD. The RD denies the request by sending the address
of the related AS, as discussed in section 5.1 of of the related AS, as discussed in section 5.1 of
[I-D.ietf-ace-oauth-authz]. The client MUST send an authorization [I-D.ietf-ace-oauth-authz]. The client MUST send an authorization
request to the AS. When appropriate, the AS returns a token that request to the AS. When appropriate, the AS returns a token that
specifies the authorization permission which needs to be specified in specifies the authorization permission which needs to be specified in
a separate document. a separate document.
8.2. Secure RD filtering 7.2. Secure RD filtering
The authorized parameter values for the queries by a given endpoint The authorized parameter values for the queries by a given endpoint
must be registered by the AS. The AS communicates the parameter must be registered by the AS. The AS communicates the parameter
values in the token. A separate document needs to specify the values in the token. A separate document needs to specify the
parameter value combinations and their storage in the token. The RD parameter value combinations and their storage in the token. The RD
decodes the token and checks the validity of the queries of the decodes the token and checks the validity of the queries of the
client. client.
8.3. Secure endpoint Name assignment 7.3. Secure endpoint Name assignment
This section only considers the assignment of a name to the endpoint This section only considers the assignment of a name to the endpoint
based on an automatic mechanism without use of AS. More elaborate based on an automatic mechanism without use of AS. More elaborate
protocols are out of scope. The registering endpoint is authorized protocols are out of scope. The registering endpoint is authorized
by the AS to discover the RD and add registrations. A token is by the AS to discover the RD and add registrations. A token is
provided by the AS and communicated from registering endpoint to RD. provided by the AS and communicated from registering endpoint to RD.
It is assumed that DTLS is used to secure the channel between It is assumed that DTLS is used to secure the channel between
registering endpoint and RD, where the registering endpoint is the registering endpoint and RD, where the registering endpoint is the
DTLS client. Assuming that the client is provided by a certificate DTLS client. Assuming that the client is provided by a certificate
at manufacturing time, the certificate is uniquely identified by the at manufacturing time, the certificate is uniquely identified by the
skipping to change at page 41, line 36 skipping to change at page 37, line 41
name by using the certificate identifier as endpoint name. Proof of name by using the certificate identifier as endpoint name. Proof of
possession of the endpoint name by the registering endpoint is possession of the endpoint name by the registering endpoint is
checked by encrypting the certificate identifier with the private key checked by encrypting the certificate identifier with the private key
of the registering endpoint, which the RD can decrypt with the public of the registering endpoint, which the RD can decrypt with the public
key stored in the certificate. Even simpler, the authorized key stored in the certificate. Even simpler, the authorized
registering endpoint can generate a random number (or string) that registering endpoint can generate a random number (or string) that
identifies the endpoint. The RD can check for the improbable identifies the endpoint. The RD can check for the improbable
replication of the random value. The RD MUST check that registering replication of the random value. The RD MUST check that registering
endpoint uses only one random value for each authorized endpoint. endpoint uses only one random value for each authorized endpoint.
9. Security Considerations 8. Security Considerations
The security considerations as described in Section 7 of [RFC5988] The security considerations as described in Section 7 of [RFC5988]
and Section 6 of [RFC6690] apply. The "/.well-known/core" resource and Section 6 of [RFC6690] apply. The "/.well-known/core" resource
may be protected e.g. using DTLS when hosted on a CoAP server as may be protected e.g. using DTLS when hosted on a CoAP server as
described in [RFC7252]. DTLS or TLS based security SHOULD be used on described in [RFC7252]. DTLS or TLS based security SHOULD be used on
all resource directory interfaces defined in this document. all resource directory interfaces defined in this document.
9.1. Endpoint Identification and Authentication 8.1. Endpoint Identification and Authentication
An Endpoint (name, sector) pair is unique within the et of endpoints An Endpoint (name, sector) pair is unique within the et of endpoints
regsitered by the RD. An Endpoint MUST NOT be identified by its regsitered by the RD. An Endpoint MUST NOT be identified by its
protocol, port or IP address as these may change over the lifetime of protocol, port or IP address as these may change over the lifetime of
an Endpoint. an Endpoint.
Every operation performed by an Endpoint on a resource directory Every operation performed by an Endpoint on a resource directory
SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key SHOULD be mutually authenticated using Pre-Shared Key, Raw Public Key
or Certificate based security. or Certificate based security.
skipping to change at page 42, line 22 skipping to change at page 38, line 29
to access A or B can do so. to access A or B can do so.
Now, imagine that a malicious device A wants to sabotage the device Now, imagine that a malicious device A wants to sabotage the device
B. It uses its credentials during the DTLS exchange. Then, it B. It uses its credentials during the DTLS exchange. Then, it
specifies the endpoint name of device B as the name of its own specifies the endpoint name of device B as the name of its own
endpoint in device A. If the server does not check whether the endpoint in device A. If the server does not check whether the
identifier provided in the DTLS handshake matches the identifier used identifier provided in the DTLS handshake matches the identifier used
at the CoAP layer then it may be inclined to use the endpoint name at the CoAP layer then it may be inclined to use the endpoint name
for looking up what information to provision to the malicious device. for looking up what information to provision to the malicious device.
Section 8.3 specifies an example that removes this threat for Section 7.3 specifies an example that removes this threat for
endpoints that have a certificate installed. endpoints that have a certificate installed.
9.2. Access Control 8.2. Access Control
Access control SHOULD be performed separately for the RD Access control SHOULD be performed separately for the RD registration
registration, Lookup, and group API paths, as different endpoints may and Lookup API paths, as different endpoints may be authorized to
be authorized to register with an RD from those authorized to lookup register with an RD from those authorized to lookup endpoints from
endpoints from the RD. Such access control SHOULD be performed in as the RD. Such access control SHOULD be performed in as fine-grained a
fine-grained a level as possible. For example access control for level as possible. For example access control for lookups could be
lookups could be performed either at the sector, endpoint or resource performed either at the sector, endpoint or resource level.
level.
9.3. Denial of Service Attacks 8.3. Denial of Service Attacks
Services that run over UDP unprotected are vulnerable to unknowingly Services that run over UDP unprotected are vulnerable to unknowingly
become part of a DDoS attack as UDP does not require return become part of a DDoS attack as UDP does not require return
routability check. Therefore, an attacker can easily spoof the routability check. Therefore, an attacker can easily spoof the
source IP of the target entity and send requests to such a service source IP of the target entity and send requests to such a service
which would then respond to the target entity. This can be used for which would then respond to the target entity. This can be used for
large-scale DDoS attacks on the target. Especially, if the service large-scale DDoS attacks on the target. Especially, if the service
returns a response that is order of magnitudes larger than the returns a response that is order of magnitudes larger than the
request, the situation becomes even worse as now the attack can be request, the situation becomes even worse as now the attack can be
amplified. DNS servers have been widely used for DDoS amplification amplified. DNS servers have been widely used for DDoS amplification
skipping to change at page 43, line 8 skipping to change at page 39, line 14
implicated in denial-of-service (DoS) attacks since they run on implicated in denial-of-service (DoS) attacks since they run on
unprotected UDP, there is no return routability check, and they can unprotected UDP, there is no return routability check, and they can
have a large amplification factor. The responses from the NTP server have a large amplification factor. The responses from the NTP server
were found to be 19 times larger than the request. A Resource were found to be 19 times larger than the request. A Resource
Directory (RD) which responds to wild-card lookups is potentially Directory (RD) which responds to wild-card lookups is potentially
vulnerable if run with CoAP over UDP. Since there is no return vulnerable if run with CoAP over UDP. Since there is no return
routability check and the responses can be significantly larger than routability check and the responses can be significantly larger than
requests, RDs can unknowingly become part of a DDoS amplification requests, RDs can unknowingly become part of a DDoS amplification
attack. attack.
10. IANA Considerations 9. IANA Considerations
10.1. Resource Types 9.1. Resource Types
IANA is asked to enter the following values into the Resource Type IANA is asked to enter the following values into the Resource Type
(rt=) Link Target Attribute Values sub-registry of the Constrained (rt=) Link Target Attribute Values sub-registry of the Constrained
Restful Environments (CoRE) Parameters registry defined in [RFC6690]: Restful Environments (CoRE) Parameters registry defined in [RFC6690]:
+--------------------+----------------------------+-----------------+ +--------------------+--------------------------+-------------------+
| Value | Description | Reference | | Value | Description | Reference |
+--------------------+----------------------------+-----------------+ +--------------------+--------------------------+-------------------+
| core.rd | Directory resource of an | RFCTHIS Section | | core.rd | Directory resource of an | RFCTHIS Section |
| | RD | 5.2 | | | RD | 5.2 |
| core.rd-group | Group directory resource | RFCTHIS Section | | core.rd-lookup-res | Resource lookup of an RD | RFCTHIS Section |
| | of an RD | 5.2 | | | | 5.2 |
| core.rd-lookup-res | Resource lookup of an RD | RFCTHIS Section | | core.rd-lookup-ep | Endpoint lookup of an RD | RFCTHIS Section |
| | | 5.2 | | | | 5.2 |
| core.rd-lookup-ep | Endpoint lookup of an RD | RFCTHIS Section | | core.rd-ep | Endpoint resource of an | RFCTHIS Section 6 |
| | | 5.2 | | | RD | |
| core.rd-lookup-gp | Group lookup of an RD | RFCTHIS Section | +--------------------+--------------------------+-------------------+
| | | 5.2 |
| core.rd-ep | Endpoint resource of an RD | RFCTHIS Section |
| | | 7 |
| core.rd-gp | Group resource of an RD | RFCTHIS Section |
| | | 7 |
+--------------------+----------------------------+-----------------+
10.2. IPv6 ND Resource Directory Address Option 9.2. IPv6 ND Resource Directory Address Option
This document registers one new ND option type under the sub-registry This document registers one new ND option type under the sub-registry
"IPv6 Neighbor Discovery Option Formats": "IPv6 Neighbor Discovery Option Formats":
o Resource Directory address Option (38) o Resource Directory address Option (38)
10.3. RD Parameter Registry 9.3. RD Parameter Registry
This specification defines a new sub-registry for registration and This specification defines a new sub-registry for registration and
lookup parameters called "RD Parameters" under "CoRE Parameters". lookup parameters called "RD Parameters" under "CoRE Parameters".
Although this specification defines a basic set of parameters, it is Although this specification defines a basic set of parameters, it is
expected that other standards that make use of this interface will expected that other standards that make use of this interface will
define new ones. define new ones.
Each entry in the registry must include Each entry in the registry must include
o the human readable name of the parameter, o the human readable name of the parameter,
o the short name as used in query parameters or link attributes, o the short name as used in query parameters or link attributes,
o indication of whether it can be passed as a query parameter at o indication of whether it can be passed as a query parameter at
registration of endpoints or groups, as a query parameter in registration of endpoints, as a query parameter in lookups, or be
lookups, or be expressed as a link attribute, expressed as a link attribute,
o validity requirements if any, and o validity requirements if any, and
o a description. o a description.
The query parameter MUST be both a valid URI query key [RFC3986] and The query parameter MUST be both a valid URI query key [RFC3986] and
a parmname as used in [RFC5988]. a parmname as used in [RFC5988].
The description must give details on which registrations they apply The description must give details on whether the parameter can be
to (Endpoint, group registrations or both? Can they be updated?), updated, and how it is to be processed in lookups.
and how they are to be processed in lookups.
The mechanisms around new RD parameters should be designed in such a The mechanisms around new RD parameters should be designed in such a
way that they tolerate RD implementations that are unaware of the way that they tolerate RD implementations that are unaware of the
parameter and expose any parameter passed at registration or updates parameter and expose any parameter passed at registration or updates
on in endpoint lookups. (For example, if a parameter used at on in endpoint lookups. (For example, if a parameter used at
registration were to be confidential, the registering endpoint should registration were to be confidential, the registering endpoint should
be instructed to only set that parameter if the RD advertises support be instructed to only set that parameter if the RD advertises support
for keeping it confidential at the discovery step.) for keeping it confidential at the discovery step.)
Initial entries in this sub-registry are as follows: Initial entries in this sub-registry are as follows:
skipping to change at page 45, line 20 skipping to change at page 41, line 20
| | | | | bytes | | | | | | bytes |
| Lifetime | lt | 60-4294967295 | R | Lifetime of the | | Lifetime | lt | 60-4294967295 | R | Lifetime of the |
| | | | | registration in | | | | | | registration in |
| | | | | seconds | | | | | | seconds |
| Sector | d | | RLA | Sector to which this | | Sector | d | | RLA | Sector to which this |
| | | | | endpoint belongs | | | | | | endpoint belongs |
| Registration | base | URI | RLA | The scheme, address | | Registration | base | URI | RLA | The scheme, address |
| Base URI | | | | and port and path at | | Base URI | | | | and port and path at |
| | | | | which this server is | | | | | | which this server is |
| | | | | available | | | | | | available |
| Group Name | gp | | RLA | Name of a group in |
| | | | | the RD |
| Page | page | Integer | L | Used for pagination | | Page | page | Integer | L | Used for pagination |
| Count | count | Integer | L | Used for pagination | | Count | count | Integer | L | Used for pagination |
| Endpoint | et | | RLA | Semantic name of the | | Endpoint | et | | RLA | Semantic name of the |
| Type | | | | endpoint (see | | Type | | | | endpoint (see |
| | | | | Section 10.4) | | | | | | Section 9.4) |
+--------------+-------+---------------+-----+----------------------+ +--------------+-------+---------------+-----+----------------------+
Table 2: RD Parameters Table 2: RD Parameters
(Short: Short name used in query parameters or link attributes. Use: (Short: Short name used in query parameters or link attributes. Use:
R = used at registration, L = used at lookup, A = expressed in link R = used at registration, L = used at lookup, A = expressed in link
attribute attribute
The descriptions for the options defined in this document are only The descriptions for the options defined in this document are only
summarized here. To which registrations they apply and when they are summarized here. To which registrations they apply and when they are
skipping to change at page 46, line 7 skipping to change at page 42, line 5
the payload of the registration and need not be registered?), and the the payload of the registration and need not be registered?), and the
potential for conflict with commonly used link attributes (For potential for conflict with commonly used link attributes (For
example, "if" could be used as a parameter for conditional example, "if" could be used as a parameter for conditional
registration if it were not to be used in lookup or attributes, but registration if it were not to be used in lookup or attributes, but
would make a bad parameter for lookup, because a resource lookup with would make a bad parameter for lookup, because a resource lookup with
an "if" query parameter could ambiguously filter by the registered an "if" query parameter could ambiguously filter by the registered
endpoint property or the [RFC6690] link attribute). It is expected endpoint property or the [RFC6690] link attribute). It is expected
that the registry will receive between 5 and 50 registrations in that the registry will receive between 5 and 50 registrations in
total over the next years. total over the next years.
10.3.1. Full description of the "Endpoint Type" Registration Parameter 9.3.1. Full description of the "Endpoint Type" Registration Parameter
An endpoint registering at an RD can describe itself with endpoint An endpoint registering at an RD can describe itself with endpoint
types, similar to how resources are described with Resource Types in types, similar to how resources are described with Resource Types in
[RFC6690]. An endpoint type is expressed as a string, which can be [RFC6690]. An endpoint type is expressed as a string, which can be
either a URI or one of the values defined in the Endpoint Type sub- either a URI or one of the values defined in the Endpoint Type sub-
registry. Endpoint types can be passed in the "et" query parameter registry. Endpoint types can be passed in the "et" query parameter
as part of extra-attrs at the Registration step, are shown on as part of extra-attrs at the Registration step, are shown on
endpoint lookups using the "et" target attribute, and can be filtered endpoint lookups using the "et" target attribute, and can be filtered
for using "et" as a search criterion in resource and endpoint lookup. for using "et" as a search criterion in resource and endpoint lookup.
Multiple endpoint types are given as separate query parameters or Multiple endpoint types are given as separate query parameters or
link attributes. link attributes.
Note that Endpoint Type differs from Resource Type in that it uses Note that Endpoint Type differs from Resource Type in that it uses
multiple attributes rather than space separated values. As a result, multiple attributes rather than space separated values. As a result,
Resource Directory implementations automatically support correct Resource Directory implementations automatically support correct
filtering in the lookup interfaces from the rules for unknown filtering in the lookup interfaces from the rules for unknown
endpoint attributes. endpoint attributes.
10.4. "Endpoint Type" (et=) RD Parameter values 9.4. "Endpoint Type" (et=) RD Parameter values
This specification establishes a new sub-registry under "CoRE This specification establishes a new sub-registry under "CoRE
Parameters" called '"Endpoint Type" (et=) RD Parameter values'. The Parameters" called '"Endpoint Type" (et=) RD Parameter values'. The
registry properties (required policy, requirements, template) are registry properties (required policy, requirements, template) are
identical to those of the Resource Type parameters in [RFC6690], in identical to those of the Resource Type parameters in [RFC6690], in
short: short:
The review policy is IETF Review for values starting with "core", and The review policy is IETF Review for values starting with "core", and
Specification Required for others. Specification Required for others.
The requirements to be enforced are: The requirements to be enforced are:
o The values MUST be related to the purpose described in o The values MUST be related to the purpose described in
Section 10.3.1. Section 9.3.1.
o The registered values MUST conform to the ABNF reg-rel-type o The registered values MUST conform to the ABNF reg-rel-type
definition of [RFC6690] and MUST NOT be a URI. definition of [RFC6690] and MUST NOT be a URI.
o It is recommended to use the period "." character for o It is recommended to use the period "." character for
segmentation. segmentation.
The registry is initially empty. The registry initially contains one value:
10.5. Multicast Address Registration o "core.rd-group": An application group as described in
Section 5.3.3.
9.5. Multicast Address Registration
IANA has assigned the following multicast addresses for use by CoAP IANA has assigned the following multicast addresses for use by CoAP
nodes: nodes:
IPv4 - "all CoRE resource directories" address, from the "IPv4 IPv4 - "all CoRE resource directories" address, from the "IPv4
Multicast Address Space Registry" equal to "All CoAP Nodes", Multicast Address Space Registry" equal to "All CoAP Nodes",
224.0.1.187. As the address is used for discovery that may span 224.0.1.187. As the address is used for discovery that may span
beyond a single network, it has come from the Internetwork Control beyond a single network, it has come from the Internetwork Control
Block (224.0.1.x, RFC 5771). Block (224.0.1.x, RFC 5771).
IPv6 - "all CoRE resource directories" address MCD1 (suggestions IPv6 - "all CoRE resource directories" address MCD1 (suggestions
FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the
"Variable Scope Multicast Addresses" space (RFC 3307). Note that "Variable Scope Multicast Addresses" space (RFC 3307). Note that
there is a distinct multicast address for each scope that interested there is a distinct multicast address for each scope that interested
CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local
scopes only. scopes only.
11. Examples 10. Examples
Two examples are presented: a Lighting Installation example in Two examples are presented: a Lighting Installation example in
Section 11.1 and a LWM2M example in Section 11.2. Section 10.1 and a LWM2M example in Section 10.2.
11.1. Lighting Installation 10.1. Lighting Installation
This example shows a simplified lighting installation which makes use This example shows a simplified lighting installation which makes use
of the Resource Directory (RD) with a CoAP interface to facilitate of the Resource Directory (RD) with a CoAP interface to facilitate
the installation and start up of the application code in the lights the installation and start up of the application code in the lights
and sensors. In particular, the example leads to the definition of a and sensors. In particular, the example leads to the definition of a
group and the enabling of the corresponding multicast address. No group and the enabling of the corresponding multicast address as
conclusions must be drawn on the realization of actual installation described in Section 5.3.3. No conclusions must be drawn on the
or naming procedures, because the example only "emphasizes" some of realization of actual installation or naming procedures, because the
the issues that may influence the use of the RD and does not pretend example only "emphasizes" some of the issues that may influence the
to be normative. use of the RD and does not pretend to be normative.
11.1.1. Installation Characteristics 10.1.1. Installation Characteristics
The example assumes that the installation is managed. That means The example assumes that the installation is managed. That means
that a Commissioning Tool (CT) is used to authorize the addition of that a Commissioning Tool (CT) is used to authorize the addition of
nodes, name them, and name their services. The CT can be connected nodes, name them, and name their services. The CT can be connected
to the installation in many ways: the CT can be part of the to the installation in many ways: the CT can be part of the
installation network, connected by WiFi to the installation network, installation network, connected by WiFi to the installation network,
or connected via GPRS link, or other method. or connected via GPRS link, or other method.
It is assumed that there are two naming authorities for the It is assumed that there are two naming authorities for the
installation: (1) the network manager that is responsible for the installation: (1) the network manager that is responsible for the
skipping to change at page 48, line 38 skipping to change at page 44, line 38
| Name | IPv6 address | | Name | IPv6 address |
+--------------------+----------------+ +--------------------+----------------+
| luminary1 | 2001:db8:4::1 | | luminary1 | 2001:db8:4::1 |
| luminary2 | 2001:db8:4::2 | | luminary2 | 2001:db8:4::2 |
| Presence sensor | 2001:db8:4::3 | | Presence sensor | 2001:db8:4::3 |
| Resource directory | 2001:db8:4::ff | | Resource directory | 2001:db8:4::ff |
+--------------------+----------------+ +--------------------+----------------+
Table 3: interface SLAAC addresses Table 3: interface SLAAC addresses
In Section 11.1.2 the use of resource directory during installation In Section 10.1.2 the use of resource directory during installation
is presented. is presented.
11.1.2. RD entries 10.1.2. RD entries
It is assumed that access to the DNS infrastructure is not always It is assumed that access to the DNS infrastructure is not always
possible during installation. Therefore, the SLAAC addresses are possible during installation. Therefore, the SLAAC addresses are
used in this section. used in this section.
For discovery, the resource types (rt) of the devices are important. For discovery, the resource types (rt) of the devices are important.
The lamps in the luminaries have rt: light, and the presence sensor The lamps in the luminaries have rt: light, and the presence sensor
has rt: p-sensor. The endpoints have names which are relevant to the has rt: p-sensor. The endpoints have names which are relevant to the
light installation manager. In this case luminary1, luminary2, and light installation manager. In this case luminary1, luminary2, and
the presence sensor are located in room 2-4-015, where luminary1 is the presence sensor are located in room 2-4-015, where luminary1 is
skipping to change at page 50, line 29 skipping to change at page 46, line 29
Res: 2.01 Created Res: 2.01 Created
Location-Path: /rd/4523 Location-Path: /rd/4523
The sector name d=R2-4-015 has been added for an efficient lookup The sector name d=R2-4-015 has been added for an efficient lookup
because filtering on "ep" name is more awkward. The same sector name because filtering on "ep" name is more awkward. The same sector name
is communicated to the two luminaries and the presence sensor by the is communicated to the two luminaries and the presence sensor by the
CT. CT.
The group is specified in the RD. The base parameter is set to the The group is specified in the RD. The base parameter is set to the
site-local multicast address allocated to the group. In the POST in site-local multicast address allocated to the group. In the POST in
the example below, two luminary endpoints are registered as members the example below, the resources supported by all group members are
of the group. They share a common resource set to which a multicast published.
request can be sent and executed by all members of the group.
Req: POST coap://[2001:db8:4::ff]/rd-group Req: POST coap://[2001:db8:4::ff]/rd
?gp=grp_R2-4-015&base=coap://[ff05::1] ?ep=grp_R2-4-015&et=core.rd-group&base=coap://[ff05::1]
Payload: Payload:
</rd/4521>, </light/left>;rt="light",
</rd/4522> </light/middle>;rt="light",
</light/right>;rt="light"
Res: 2.01 Created Res: 2.01 Created
Location-Path: /rd-group/501 Location-Path: /rd/501
After the filling of the RD by the CT, the application in the After the filling of the RD by the CT, the application in the
luminaries can learn to which groups they belong, and enable their luminaries can learn to which groups they belong, and enable their
interface for the multicast address. interface for the multicast address.
The luminary, knowing its sector and own IPv6 address, looks up the The luminary, knowing its sector and being configured to join any
groups containing light resources it is assigned to: group containing lights, searches for candidate groups and joins
them:
Req: GET coap://[2001:db8:4::ff]/rd-lookup/gp Req: GET coap://[2001:db8:4::ff]/rd-lookup/ep
?d=R2-4-015&base=coap://[2001:db8:4::1]&rt=light ?d=R2-4-015&et=core.rd-group&rt=light
Res: 2.05 Content Res: 2.05 Content
</rd-group/501>;gp="grp_R2-4-015";base="coap://[ff05::1]" </rd/501>;ep="grp_R2-4-015";et="core.rd-group";
base="coap://[ff05::1]"
From the returned base parameter value, the luminary learns the From the returned base parameter value, the luminary learns the
multicast address of the multicast group. multicast address of the multicast group.
Alternatively, the CT can communicate the multicast address directly Alternatively, the CT can communicate the multicast address directly
to the luminaries by using the "coap-group" resource specified in to the luminaries by using the "coap-group" resource specified in
[RFC7390]. [RFC7390].
Req: POST coap://[2001:db8:4::1]/coap-group Req: POST coap://[2001:db8:4::1]/coap-group
Content-Format: application/coap-group+json Content-Format: application/coap-group+json
Payload: Payload:
{ "a": "[ff05::1]", "n": "grp_R2-4-015"} { "a": "[ff05::1]", "n": "grp_R2-4-015"}
Res: 2.01 Created Res: 2.01 Created
Location-Path: /coap-group/1 Location-Path: /coap-group/1
Dependent on the situation, only the address, "a", or the name, "n", Dependent on the situation, only the address, "a", or the name, "n",
is specified in the coap-group resource. is specified in the coap-group resource.
The presence sensor can learn the presence of groups that support The presence sensor can learn the presence of groups that support
resources with rt=light in its own sector by sending the request: resources with rt=light in its own sector by sending the same
request, as used by the luminary. The presence sensor learns the
Req: GET coap://[2001:db8:4::ff]/rd-lookup/gp?d=R2-4-015&rt=light multicast address to use for sending messages to the luminaries.
Res: 2.05 Content
</rd-group/501>;gp="grp_R2-4-015";base="coap://[ff05::1]"
The presence sensor learns the multicast address to use for sending
messages to the luminaries.
11.2. OMA Lightweight M2M (LWM2M) Example 10.2. OMA Lightweight M2M (LWM2M) Example
This example shows how the OMA LWM2M specification makes use of This example shows how the OMA LWM2M specification makes use of
Resource Directory (RD). Resource Directory (RD).
OMA LWM2M is a profile for device services based on CoAP(OMA Name OMA LWM2M is a profile for device services based on CoAP(OMA Name
Authority). LWM2M defines a simple object model and a number of Authority). LWM2M defines a simple object model and a number of
abstract interfaces and operations for device management and device abstract interfaces and operations for device management and device
service enablement. service enablement.
An LWM2M server is an instance of an LWM2M middleware service layer, An LWM2M server is an instance of an LWM2M middleware service layer,
containing a Resource Directory along with other LWM2M interfaces containing a Resource Directory along with other LWM2M interfaces
defined by the LWM2M specification. defined by the LWM2M specification.
CoRE Resource Directory (RD) is used to provide the LWM2M CoRE Resource Directory (RD) is used to provide the LWM2M
Registration interface. Registration interface.
LWM2M does not provide for registration sectors and does not LWM2M does not provide for registration sectors and does not
currently use the rd-group or rd-lookup interfaces. currently use the rd-lookup interface.
The LWM2M specification describes a set of interfaces and a resource The LWM2M specification describes a set of interfaces and a resource
model used between a LWM2M device and an LWM2M server. Other model used between a LWM2M device and an LWM2M server. Other
interfaces, proxies, and applications are currently out of scope for interfaces, proxies, and applications are currently out of scope for
LWM2M. LWM2M.
The location of the LWM2M Server and RD URI path is provided by the The location of the LWM2M Server and RD URI path is provided by the
LWM2M Bootstrap process, so no dynamic discovery of the RD is used. LWM2M Bootstrap process, so no dynamic discovery of the RD is used.
LWM2M Servers and endpoints are not required to implement the /.well- LWM2M Servers and endpoints are not required to implement the /.well-
known/core resource. known/core resource.
11.2.1. The LWM2M Object Model 10.2.1. The LWM2M Object Model
The OMA LWM2M object model is based on a simple 2 level class The OMA LWM2M object model is based on a simple 2 level class
hierarchy consisting of Objects and Resources. hierarchy consisting of Objects and Resources.
An LWM2M Resource is a REST endpoint, allowed to be a single value or An LWM2M Resource is a REST endpoint, allowed to be a single value or
an array of values of the same data type. an array of values of the same data type.
An LWM2M Object is a resource template and container type that An LWM2M Object is a resource template and container type that
encapsulates a set of related resources. An LWM2M Object represents encapsulates a set of related resources. An LWM2M Object represents
a specific type of information source; for example, there is a LWM2M a specific type of information source; for example, there is a LWM2M
skipping to change at page 53, line 34 skipping to change at page 49, line 32
example, a LWM2M URI might be: example, a LWM2M URI might be:
/1/0/1 /1/0/1
The base uri is empty, the Object ID is 1, the instance ID is 0, the The base uri is empty, the Object ID is 1, the instance ID is 0, the
resource ID is 1, and the resource instance is "undefined". This resource ID is 1, and the resource instance is "undefined". This
example URI points to internal resource 1, which represents the example URI points to internal resource 1, which represents the
registration lifetime configured, in instance 0 of a type 1 object registration lifetime configured, in instance 0 of a type 1 object
(LWM2M Server Object). (LWM2M Server Object).
11.2.2. LWM2M Register Endpoint 10.2.2. LWM2M Register Endpoint
LWM2M defines a registration interface based on the REST API, LWM2M defines a registration interface based on the REST API,
described in Section 5. The RD registration URI path of the LWM2M described in Section 5. The RD registration URI path of the LWM2M
Resource Directory is specified to be "/rd". Resource Directory is specified to be "/rd".
LWM2M endpoints register object IDs, for example </1>, to indicate LWM2M endpoints register object IDs, for example </1>, to indicate
that a particular object type is supported, and register object that a particular object type is supported, and register object
instances, for example </1/0>, to indicate that a particular instance instances, for example </1/0>, to indicate that a particular instance
of that object type exists. of that object type exists.
skipping to change at page 55, line 7 skipping to change at page 51, line 5
Here is an example LWM2M registration payload: Here is an example LWM2M registration payload:
</1>,</1/0>,</3/0>,</5> </1>,</1/0>,</3/0>,</5>
This link format payload indicates that object ID 1 (LWM2M Server This link format payload indicates that object ID 1 (LWM2M Server
Object) is supported, with a single instance 0 existing, object ID 3 Object) is supported, with a single instance 0 existing, object ID 3
(LWM2M Device object) is supported, with a single instance 0 (LWM2M Device object) is supported, with a single instance 0
existing, and object 5 (LWM2M Firmware Object) is supported, with no existing, and object 5 (LWM2M Firmware Object) is supported, with no
existing instances. existing instances.
11.2.3. LWM2M Update Endpoint Registration 10.2.3. LWM2M Update Endpoint Registration
The LwM2M update is really very similar to the registration update as The LwM2M update is really very similar to the registration update as
described in Appendix A.1, with the only difference that there are described in Appendix A.1, with the only difference that there are
more parameters defined and available. All the parameters listed in more parameters defined and available. All the parameters listed in
that section are also available with the initial registration but are that section are also available with the initial registration but are
all optional: all optional:
lt - Registration Lifetime lt - Registration Lifetime
b - Protocol Binding b - Protocol Binding
sms - MSISDN sms - MSISDN
link payload - new or modified links link payload - new or modified links
A Registration update is also specified to be used to update the A Registration update is also specified to be used to update the
LWM2M server whenever the endpoint's UDP port or IP address are LWM2M server whenever the endpoint's UDP port or IP address are
changed. changed.
11.2.4. LWM2M De-Register Endpoint 10.2.4. LWM2M De-Register Endpoint
LWM2M allows for de-registration using the delete method on the LWM2M allows for de-registration using the delete method on the
returned location from the initial registration operation. LWM2M de- returned location from the initial registration operation. LWM2M de-
registration proceeds as described in Appendix A.2. registration proceeds as described in Appendix A.2.
12. Acknowledgments 11. Acknowledgments
Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have Hannes Tschofenig, Sampo Ukkola, Linyi Tian, and Jan Newmarch have
provided helpful comments, discussions and ideas to improve and shape provided helpful comments, discussions and ideas to improve and shape
this document. Zach would also like to thank his colleagues from the this document. Zach would also like to thank his colleagues from the
EU FP7 SENSEI project, where many of the resource directory concepts EU FP7 SENSEI project, where many of the resource directory concepts
were originally developed. were originally developed.
13. Changelog 12. Changelog
changes from -15 to -16 changes from -16 to -17
(Note that -17 is published as a direct follow-up to -16, containing
a single change to be discussed at IETF103)
o Removed groups that are enumerations of registrations and have
dedicated mechanism
o Add groups that are enumerations of shared resources and are a
special case of endpoint registrations
changes from -15 to -16
o Recommend a common set of resources for members of a group o Recommend a common set of resources for members of a group
o Clarified use of multicast group in lighting example o Clarified use of multicast group in lighting example
o Add note on concurrent registrations from one EP being possible o Add note on concurrent registrations from one EP being possible
but not expected but not expected
o Refresh web examples appendix to reflect current use of Modernized o Refresh web examples appendix to reflect current use of Modernized
Link Format Link Format
skipping to change at page 62, line 32 skipping to change at page 58, line 35
o Added the concept of an RD Domain and a registration parameter for o Added the concept of an RD Domain and a registration parameter for
it. it.
o Recommended the Location returned from a registration to be o Recommended the Location returned from a registration to be
stable, allowing for endpoint and Domain information to be changed stable, allowing for endpoint and Domain information to be changed
during updates. during updates.
o Changed the lookup interface to accept endpoint and Domain as o Changed the lookup interface to accept endpoint and Domain as
query string parameters to control the scope of a lookup. query string parameters to control the scope of a lookup.
14. References 13. References
14.1. Normative References 13.1. Normative References
[I-D.ietf-core-links-json] [I-D.ietf-core-links-json]
Li, K., Rahman, A., and C. Bormann, "Representing Li, K., Rahman, A., and C. Bormann, "Representing
Constrained RESTful Environments (CoRE) Link Format in Constrained RESTful Environments (CoRE) Link Format in
JSON and CBOR", draft-ietf-core-links-json-10 (work in JSON and CBOR", draft-ietf-core-links-json-10 (work in
progress), February 2018. progress), February 2018.
[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,
skipping to change at page 63, line 27 skipping to change at page 59, line 32
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>. <https://www.rfc-editor.org/info/rfc6763>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
14.2. Informative References 13.2. Informative References
[ER] Chen, P., "The entity-relationship model---toward a [ER] Chen, P., "The entity-relationship model---toward a
unified view of data", ACM Transactions on Database unified view of data", ACM Transactions on Database
Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March Systems Vol. 1, pp. 9-36, DOI 10.1145/320434.320440, March
1976. 1976.
[I-D.arkko-core-dev-urn] [I-D.arkko-core-dev-urn]
Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource
Names for Device Identifiers", draft-arkko-core-dev-urn-05 Names for Device Identifiers", draft-arkko-core-dev-urn-05
(work in progress), October 2017. (work in progress), October 2017.
skipping to change at page 65, line 30 skipping to change at page 61, line 40
After the initial registration, the registering endpoint retains the After the initial registration, the registering endpoint retains the
returned location of the Registration Resource for further returned location of the Registration Resource for further
operations, including refreshing the registration in order to extend operations, including refreshing the registration in order to extend
the lifetime and "keep-alive" the registration. When the lifetime of the lifetime and "keep-alive" the registration. When the lifetime of
the registration has expired, the RD SHOULD NOT respond to discovery the registration has expired, the RD SHOULD NOT respond to discovery
queries concerning this endpoint. The RD SHOULD continue to provide queries concerning this endpoint. The RD SHOULD continue to provide
access to the Registration Resource after a registration time-out access to the Registration Resource after a registration time-out
occurs in order to enable the registering endpoint to eventually occurs in order to enable the registering endpoint to eventually
refresh the registration. The RD MAY eventually remove the refresh the registration. The RD MAY eventually remove the
registration resource for the purpose of garbage collection and registration resource for the purpose of garbage collection. If the
remove it from any group it belongs to. If the Registration Resource Registration Resource is removed, the corresponding endpoint will
is removed, the corresponding endpoint will need to be re-registered. need to be re-registered.
The Registration Resource may also be used to inspect the The Registration Resource may also be used to inspect the
registration resource using GET, update the registration, cancel the registration resource using GET, update the registration, cancel the
registration using DELETE, do an endpoint lookup, or a group lookup. registration using DELETE, or do an endpoint lookup.
These operations are described below. These operations are described below.
A.1. Registration Update A.1. Registration Update
The update interface is used by the registering endpoint to refresh The update interface is used by the registering endpoint to refresh
or update its registration with an RD. To use the interface, the or update its registration with an RD. To use the interface, the
registering endpoint sends a POST request to the registration registering endpoint sends a POST request to the registration
resource returned by the initial registration operation. resource returned by the initial registration operation.
skipping to change at page 68, line 33 skipping to change at page 64, line 48
Req: GET /rd-lookup/res?ep=endpoint1 Req: GET /rd-lookup/res?ep=endpoint1
Res: 2.01 Content Res: 2.01 Content
Payload: Payload:
<coaps://new.example.com:5684/sensors/temp>;ct=41;rt="temperature"; <coaps://new.example.com:5684/sensors/temp>;ct=41;rt="temperature";
anchor="coap://spurious.example.com:5683", anchor="coap://spurious.example.com:5683",
<coaps://new.example.com:5684/sensors/light>;ct=41;rt="light-lux"; <coaps://new.example.com:5684/sensors/light>;ct=41;rt="light-lux";
if="sensor"; anchor="coaps://new.example.com:5684", if="sensor"; anchor="coaps://new.example.com:5684",
The following example shows a client performing and enpoint lookup
for all groups.
Req: GET /rd-lookup/ep?et=core.rd-group
Res: 2.01 Content
Payload:
</rd/501>;ep="GRP_R2-4-015";et="core.rd-group";
base="coap://[ff05:;1]",
<rd/12>;ep=lights&et=core.rd-group;
base="coap://[ff35:30:2001:db8::1]"
A.2. Registration Removal A.2. Registration Removal
Although RD entries have soft state and will eventually timeout after Although RD entries have soft state and will eventually timeout after
their lifetime, the registering endpoint SHOULD explicitly remove an their lifetime, the registering endpoint SHOULD explicitly remove an
entry from the RD if it knows it will no longer be available (for entry from the RD if it knows it will no longer be available (for
example on shut-down). This is accomplished using a removal example on shut-down). This is accomplished using a removal
interface on the RD by performing a DELETE on the endpoint resource. interface on the RD by performing a DELETE on the endpoint resource.
Removed registrations are implicitly removed from the groups to which
they belong.
The removal request interface is specified as follows: The removal request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> RD
Method: DELETE Method: DELETE
URI Template: {+location} URI Template: {+location}
URI Template Variables: URI Template Variables:
skipping to change at page 71, line 5 skipping to change at page 67, line 30
</sensors/light>;ct=41;rt="light-lux";if="sensor" </sensors/light>;ct=41;rt="light-lux";if="sensor"
A.4. Update Endpoint Links A.4. Update Endpoint Links
An iPATCH (or PATCH) update ([RFC8132]) can add, remove or change the An iPATCH (or PATCH) update ([RFC8132]) can add, remove or change the
links of a registration. links of a registration.
Those operations are out of scope of this document, and will require Those operations are out of scope of this document, and will require
media types suitable for modifying sets of links. media types suitable for modifying sets of links.
A.5. Endpoint and group lookup A.5. Endpoint lookup
Endpoint and group lookups result in links to registration resources
and group resources, respectively. Endpoint registration resources
are annotated with their endpoint names (ep), sectors (d, if present)
and registration base URI (base) as well as a constant resource type
(rt="core.rd-ep"); the lifetime (lt) is not reported. Additional
endpoint attributes are added as link attributes to their endpoint
link unless their specification says otherwise.
Group resources are annotated with their group names (gp), sector (d, Endpoint lookups result in links to registration resources. Endpoint
if present) and multicast address (base, if present) as well as a registration resources are annotated with their endpoint names (ep),
constant resource type (rt="core.rd-gp"). sectors (d, if present) and registration base URI (base) as well as a
constant resource type (rt="core.rd-ep"); the lifetime (lt) is not
reported. Additional endpoint attributes are added as link
attributes to their endpoint link unless their specification says
otherwise.
Serializations derived from Link Format, SHOULD present links to Serializations derived from Link Format, SHOULD present links to
groups and endpoints in path-absolute form or, if required, as endpoints in path-absolute form or, if required, as absolute
absolute references. (This approach avoids the RFC6690 ambiguities.) references. (This approach avoids the RFC6690 ambiguities.)
While Endpoint Lookup does expose the registration resources, the RD While Endpoint Lookup does expose the registration resources, the RD
does not need to make them accessible to clients. Clients SHOULD NOT does not need to make them accessible to clients. Clients SHOULD NOT
attempt to dereference or manipulate them. attempt to dereference or manipulate them.
A Resource Directory can report endpoints or groups in lookup that A Resource Directory can report endpoints in lookup that are not
are not hosted at the same address. Lookup clients MUST be prepared hosted at the same address. Lookup clients MUST be prepared to see
to see arbitrary URIs as registration or group resources in the arbitrary URIs as registration resources in the results and treat
results and treat them as opaque identifiers; the precise semantics them as opaque identifiers; the precise semantics of such links are
of such links are left to future specifications. left to future specifications.
For groups, a Resource Directory as specified here does not provide a
lookup mechanism for the resources that can be accessed on a group's
multicast address (i.e. no lookup will return links like
"<coap://[ff35:30:2001:db8::1]/light>;..." for a group registered
with "base=coap://[ff35...]"). Such an additional lookup interface
could be specified in an extension document.
The following example shows a client performing an endpoint type (et) The following example shows a client performing an endpoint type (et)
lookup with the value oic.d.sensor (which is currently a registered lookup with the value oic.d.sensor (which is currently a registered
rt value): rt value):
Req: GET /rd-lookup/ep?et=oic.d.sensor Req: GET /rd-lookup/ep?et=oic.d.sensor
Res: 2.05 Content Res: 2.05 Content
</rd/1234>;base="coap://[2001:db8:3::127]:61616";ep="node5"; </rd/1234>;base="coap://[2001:db8:3::127]:61616";ep="node5";
et="oic.d.sensor";ct="40", et="oic.d.sensor";ct="40",
</rd/4521>;base="coap://[2001:db8:3::129]:61616";ep="node7"; </rd/4521>;base="coap://[2001:db8:3::129]:61616";ep="node7";
et="oic.d.sensor";ct="40";d="floor-3" et="oic.d.sensor";ct="40";d="floor-3"
The following example shows a client performing a group lookup for
all groups:
Req: GET /rd-lookup/gp
Res: 2.05 Content
</rd-group/1>;gp="lights1";d="example.com";
base="coap://[ff35:30:2001:db8::1]",
</rd-group/2>;gp="lights2";d="example.com";
base="coap://[ff35:30:2001:db8::2]"
The following example shows a client performing a lookup for all
groups the endpoint "node1" belongs to:
Req: GET /rd-lookup/gp?ep=node1
Res: 2.05 Content
</rd-group/1>;gp="lights1"
Appendix B. Web links and the Resource Directory Appendix B. Web links and the Resource Directory
Understanding the semantics of a link-format document and its URI Understanding the semantics of a link-format document and its URI
references is a journey through different documents ([RFC3986] references is a journey through different documents ([RFC3986]
defining URIs, [RFC6690] defining link-format documents based on defining URIs, [RFC6690] defining link-format documents based on
[RFC8288] which defines link headers, and [RFC7252] providing the [RFC8288] which defines link headers, and [RFC7252] providing the
transport). This appendix summarizes the mechanisms and semantics at transport). This appendix summarizes the mechanisms and semantics at
play from an entry in ".well-known/core" to a resource lookup. play from an entry in ".well-known/core" to a resource lookup.
 End of changes. 102 change blocks. 
454 lines changed or deleted 295 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/