draft-ietf-core-resource-directory-06.txt   draft-ietf-core-resource-directory-07.txt 
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft M. Koster Internet-Draft ARM
Intended status: Standards Track ARM Intended status: Standards Track M. Koster
Expires: September 22, 2016 C. Bormann Expires: September 22, 2016 SmartThings
C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
P. van der Stok P. van der Stok
consultant consultant
March 21, 2016 March 21, 2016
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-06 draft-ietf-core-resource-directory-07
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
descriptions of resources held on other servers, allowing lookups to descriptions 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 in order for web interfaces that a Resource Directory supports in order for web
skipping to change at page 2, line 30 skipping to change at page 2, line 35
3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6 3.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . 6
3.2. Use Case: Home and Building Automation . . . . . . . . . 7 3.2. Use Case: Home and Building Automation . . . . . . . . . 7
3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7 3.3. Use Case: Link Catalogues . . . . . . . . . . . . . . . . 7
4. Simple Directory Discovery . . . . . . . . . . . . . . . . . 8 4. Simple Directory Discovery . . . . . . . . . . . . . . . . . 8
4.1. Finding a Directory Server . . . . . . . . . . . . . . . 9 4.1. Finding a Directory Server . . . . . . . . . . . . . . . 9
4.2. Third-party registration . . . . . . . . . . . . . . . . 10 4.2. Third-party registration . . . . . . . . . . . . . . . . 10
5. Resource Directory Function Set . . . . . . . . . . . . . . . 10 5. Resource Directory Function Set . . . . . . . . . . . . . . . 10
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Registration . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.4. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.5. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 17 5.5. Read Endpoint Links . . . . . . . . . . . . . . . . . . . 18
5.6. Update Endpoint Links . . . . . . . . . . . . . . . . . . 19 5.6. Update Endpoint Links . . . . . . . . . . . . . . . . . . 19
6. Group Function Set . . . . . . . . . . . . . . . . . . . . . 21 6. Group Function Set . . . . . . . . . . . . . . . . . . . . . 22
6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 22 6.1. Register a Group . . . . . . . . . . . . . . . . . . . . 22
6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 24 6.2. Group Removal . . . . . . . . . . . . . . . . . . . . . . 24
7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 25 7. RD Lookup Function Set . . . . . . . . . . . . . . . . . . . 25
8. New Link-Format Attributes . . . . . . . . . . . . . . . . . 29 8. New Link-Format Attributes . . . . . . . . . . . . . . . . . 29
8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 29 8.1. Resource Instance attribute 'ins' . . . . . . . . . . . . 30
8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 30 8.2. Export attribute 'exp' . . . . . . . . . . . . . . . . . 30
9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 30 9. DNS-SD Mapping . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 30 9.1. DNS-based Service discovery . . . . . . . . . . . . . . . 31
9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 31 9.2. mapping ins to <Instance> . . . . . . . . . . . . . . . . 32
9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 32 9.3. Mapping rt to <ServiceType> . . . . . . . . . . . . . . . 32
9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 32 9.4. Domain mapping . . . . . . . . . . . . . . . . . . . . . 33
9.5. TXT Record key=value strings . . . . . . . . . . . . . . 32 9.5. TXT Record key=value strings . . . . . . . . . . . . . . 33
9.6. Importing resource links into DNS-SD . . . . . . . . . . 33 9.6. Importing resource links into DNS-SD . . . . . . . . . . 33
10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10.1. Endpoint Identification and Authentication . . . . . . . 34 10.1. Endpoint Identification and Authentication . . . . . . . 34
10.2. Access Control . . . . . . . . . . . . . . . . . . . . . 34 10.2. Access Control . . . . . . . . . . . . . . . . . . . . . 35
10.3. Denial of Service Attacks . . . . . . . . . . . . . . . 34 10.3. Denial of Service Attacks . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 35 11.1. Resource Types . . . . . . . . . . . . . . . . . . . . . 35
11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 35 11.2. Link Extension . . . . . . . . . . . . . . . . . . . . . 36
11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 35 11.3. RD Parameter Registry . . . . . . . . . . . . . . . . . 36
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Lighting Installation . . . . . . . . . . . . . . . . . 36 12.1. Lighting Installation . . . . . . . . . . . . . . . . . 37
12.1.1. Installation Characteristics . . . . . . . . . . . . 36 12.1.1. Installation Characteristics . . . . . . . . . . . . 37
12.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 38 12.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 38
12.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 41 12.1.3. DNS entries . . . . . . . . . . . . . . . . . . . . 42
12.1.4. RD Operation . . . . . . . . . . . . . . . . . . . . 44 12.1.4. RD Operation . . . . . . . . . . . . . . . . . . . . 45
12.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 44 12.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 45
12.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 45 12.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 46
12.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 46 12.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 47
12.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 47 12.2.3. Alternate Base URI . . . . . . . . . . . . . . . . . 48
12.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 48 12.2.4. LWM2M Update Endpoint Registration . . . . . . . . . 49
12.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 48 12.2.5. LWM2M De-Register Endpoint . . . . . . . . . . . . . 49
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 48 14. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 49
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
15.1. Normative References . . . . . . . . . . . . . . . . . . 51 15.1. Normative References . . . . . . . . . . . . . . . . . . 52
15.2. Informative References . . . . . . . . . . . . . . . . . 52 15.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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
important in machine-to-machine applications where there are no important in machine-to-machine applications where there are no
humans in the loop and static interfaces result in fragility. The humans in the loop and static interfaces result in fragility. The
discovery of resources provided by an HTTP Web Server is typically discovery of resources provided by an HTTP Web Server is typically
called Web Linking [RFC5988]. The use of Web Linking for the called Web Linking [RFC5988]. The use of Web Linking for the
description and discovery of resources hosted by constrained web description and discovery of resources hosted by constrained web
servers is specified by the CoRE Link Format [RFC6690]. This servers is specified by the CoRE Link Format [RFC6690]. However,
specification however only describes how to discover resources from [RFC6690] only describes how to discover resources from the web
the web server that hosts them by requesting "/.well-known/core". In server that hosts them by requesting "/.well-known/core". In many
many M2M scenarios, direct discovery of resources is not practical M2M scenarios, direct discovery of resources is not practical due to
due to sleeping nodes, disperse networks, or networks where multicast sleeping nodes, disperse networks, or networks where multicast
traffic is inefficient. These problems can be solved by employing an traffic is inefficient. These problems can be solved by employing an
entity called a Resource Directory (RD), which hosts descriptions of entity called a Resource Directory (RD), which hosts descriptions of
resources held on other servers, allowing lookups to be performed for resources held on other servers, allowing lookups to be performed for
those resources. those resources.
This document specifies the web interfaces that a Resource Directory This document specifies the web interfaces that a Resource Directory
supports in order for web servers to discover the RD and to register, supports in order for web servers to discover the RD and to register,
maintain, lookup and remove resource descriptions. Furthermore, new maintain, lookup and remove resource descriptions. Furthermore, new
link attributes useful in conjunction with a Resource Directory are link attributes useful in conjunction with a Resource Directory are
defined. Although the examples in this document show the use of defined. Although the examples in this document show the use of
skipping to change at page 7, line 49 skipping to change at page 7, line 49
public consumption may provide the data to an intermediary server, or public consumption may provide the data to an intermediary server, or
broker. Sensor data are published to the intermediary upon changes broker. Sensor data are published to the intermediary upon changes
or at regular intervals. Descriptions of the sensors that resolve to or at regular intervals. Descriptions of the sensors that resolve to
links to sensor data may be published to a Resource Directory. links to sensor data may be published to a Resource Directory.
Applications wishing to consume the data can use the Resource Applications wishing to consume the data can use the Resource
Directory lookup function set to discover and resolve links to the Directory lookup function set to discover and resolve links to the
desired resources and endpoints. The Resource Directory service need desired resources and endpoints. The Resource Directory service need
not be coupled with the data intermediary service. Mapping of not be coupled with the data intermediary service. Mapping of
Resource Directories to data intermediaries may be many-to-many. Resource Directories to data intermediaries may be many-to-many.
Metadata in link-format, link-format+cbor, or link-format+json Metadata in web link compatible representations are supplied by
representations are supplied by Resource Directories, which may be Resource Directories, which may be internally stored as triples, or
internally stored as triples, or relation/attribute pairs providing relation/attribute pairs providing metadata about resource links.
metadata about resource links. External catalogs that are
represented in other formats may be converted to link-format, link- External catalogs that are represented in other formats may be
format+json, or link-format+cbor for storage and access by Resource converted to common web linking formats for storage and access by
Directories. Since it is common practice for these to be URN Resource Directories. Since it is common practice for these to be
encoded, simple and lossless structural transforms will generally be URN encoded, simple and lossless structural transforms should
sufficient to store external metadata in Resource Directories. generally be sufficient to store external metadata in Resource
Directories.
The additional features of Resource Directory allow domains to be The additional features of Resource Directory allow domains 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. Resource groups may defined to allow sensitive data when needed. Resource groups may defined to allow
batched reads from multiple resources. batched reads from multiple resources.
4. Simple Directory Discovery 4. Simple Directory Discovery
Not all endpoints hosting resources are expected to know how to Not all endpoints hosting resources are expected to know how to
skipping to change at page 11, line 10 skipping to change at page 11, line 10
request to "/.well-known/core" and including a Resource Type (rt) request to "/.well-known/core" and including a Resource Type (rt)
parameter [RFC6690] with the value "core.rd" in the query string. parameter [RFC6690] with the value "core.rd" in the query string.
Likewise, a Resource Type parameter value of "core.rd-lookup" is used Likewise, a Resource Type parameter value of "core.rd-lookup" is used
to discover the RD Lookup Function Set. Upon success, the response to discover the RD Lookup Function Set. Upon success, the response
will contain a payload with a link format entry for each RD will contain a payload with a link format entry for each RD
discovered, with the URL indicating the root resource of the RD. discovered, with the URL indicating the root resource of the RD.
When performing multicast discovery, the multicast IP address used When performing multicast discovery, the multicast IP address used
will depend on the scope required and the multicast capabilities of will depend on the scope required and the multicast capabilities of
the network. the network.
HTTP does not support multicast and consequently discovery has no A Resource Directory MAY provide hints about the content-formats it
HTTP interface. supports in the links it exposes or registers, using the "ct" link
attribute, as shown in the example below. Clients MAY use these
hints to select alternate content-formats for interaction with the
Resource Directory.
HTTP does not support multicast and consequently only unicast
discovery can be supported using HTTP. Links to Resource Directories
MAY be registered in other Resource Directories, and well-known entry
points SHOULD be provided to enable the bootstrapping of unicast
discovery.
An RD implementation of this specification MUST support query An RD implementation of this specification MUST support query
filtering for the rt parameter as defined in [RFC6690]. filtering for the rt parameter as defined in [RFC6690].
The discovery request interface is specified as follows: The discovery request interface is specified as follows:
Interaction: EP -> RD Interaction: EP -> 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 (optional). MAY contain the value "core.rd", rt := Resource Type (optional). MAY contain one or more of the
"core.rd-lookup", "core.rd-group" or "core.rd*" values "core.rd", "core.rd-lookup", "core.rd-group" or
"core.rd*"
Content-Type: application/link-format (if any) Content-Format: application/link-format (if any)
Content-Type: application/link-format+json (if any) Content-Format: application/link-format+json (if any)
Content-Type: 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" with an application/link-format, Success: 2.05 "Content" 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.04 "Not Found" is returned in case no matching entry is Failure: 4.04 "Not Found" is returned in case no matching entry is
found for a unicast request. found for a unicast request.
skipping to change at page 12, line 21 skipping to change at page 12, line 32
| | | |
| ----- GET /.well-known/core?rt=core.rd* ------> | | ----- GET /.well-known/core?rt=core.rd* ------> |
| | | |
| | | |
| <---- 2.05 Content "</rd>;rt="core.rd" ------- | | <---- 2.05 Content "</rd>;rt="core.rd" ------- |
| | | |
Req: GET coap://[ff02::1]/.well-known/core?rt=core.rd* Req: GET coap://[ff02::1]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
</rd>;rt="core.rd", </rd>;rt="core.rd";ct="application/link-format+cbor",
</rd-lookup>;rt="core.rd-lookup", </rd-lookup>;rt="core.rd-lookup";ct="application/link-format+cbor",
</rd-group>;rt="core.rd-group" </rd-group>;rt="core.rd-group";ct="application/link-format+cbor"
5.2. Registration 5.2. Registration
After discovering the location of an RD Function Set, an endpoint MAY After discovering the location of an RD Function Set, an endpoint MAY
register its resources using the registration interface. This register its resources using the registration interface. This
interface accepts a POST from an endpoint containing the list of interface accepts a POST from an endpoint containing the list of
resources to be added to the directory as the message payload in the resources to be added to the directory as the message payload in the
CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link- CoRE Link Format [RFC6690], JSON CoRE Link Format (application/link-
format+json), or CBOR CoRE Link Format (application/link-format+cbor) format+json), or CBOR CoRE Link Format (application/link-format+cbor)
[I-D.ietf-core-links-json], along with query string parameters [I-D.ietf-core-links-json], along with query string parameters
skipping to change at page 13, line 44 skipping to change at page 14, line 5
a default value of 86400 (24 hours) SHOULD be assumed. a default value of 86400 (24 hours) SHOULD be assumed.
con := Context (optional). This parameter sets the scheme, con := Context (optional). This parameter sets the scheme,
address and port at which this server is available in the form address and port at which this server is available in the form
scheme://host:port. Optional. In the absence of this scheme://host:port. Optional. In the absence of this
parameter the scheme of the protocol, source IP address and parameter the scheme of the protocol, source IP address and
source port of the register request are assumed. This source port of the register request are assumed. This
parameter is mandatory when the directory is filled by a third parameter is mandatory when the directory is filled by a third
party such as an installation tool. party such as an installation tool.
Content-Type: application/link-format Content-Format: application/link-format
Content-Type: application/link-format+json Content-Format: application/link-format+json
Content-Type: application/link-format+cbor Content-Format: application/link-format+cbor
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created" or 201 "Created". The Location header MUST Success: 2.01 "Created" or 201 "Created". The Location header MUST
be included with the new resource entry for the endpoint. This be included with the new resource entry for the endpoint. This
Location MUST be a stable identifier generated by the RD as it is Location MUST be a stable identifier generated by the RD as it is
used for all subsequent operations on this registration. The used for all subsequent operations on this registration. The
resource returned in the Location is only for the purpose of the resource returned in the Location is only for the purpose of the
Update (POST) and Removal (DELETE), and MUST NOT implement GET or Update (POST) and Removal (DELETE), and MUST NOT implement GET or
PUT methods. PUT methods.
skipping to change at page 14, line 42 skipping to change at page 15, line 4
| | | |
Req: POST coap://rd.example.com/rd?ep=node1 Req: POST coap://rd.example.com/rd?ep=node1
Content-Format: 40 Content-Format: 40
Payload: Payload:
</sensors/temp>;ct=41;rt="temperature-c";if="sensor", </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
</sensors/light>;ct=41;rt="light-lux";if="sensor" </sensors/light>;ct=41;rt="light-lux";if="sensor"
Res: 2.01 Created Res: 2.01 Created
Location: /rd/4521 Location: /rd/4521
Req: POST /rd?ep=node1 HTTP/1.1 Req: POST /rd?ep=node1 HTTP/1.1
Host : example.com Host : example.com
Content-Type: application/link-format Content-Format: application/link-format
Payload: Payload:
</sensors/temp>;ct=41;rt="temperature-c";if="sensor", </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
</sensors/light>;ct=41;rt="light-lux";if="sensor" </sensors/light>;ct=41;rt="light-lux";if="sensor"
Res: 201 Created Res: 201 Created
Location: /rd/4521 Location: /rd/4521
5.3. Update 5.3. Update
The update interface is used by an endpoint to refresh or update its The update interface is used by an endpoint to refresh or update its
skipping to change at page 15, line 50 skipping to change at page 16, line 13
a default value of 86400 (24 hours) SHOULD be assumed. a default value of 86400 (24 hours) SHOULD be assumed.
con := Context (optional). This parameter sets the scheme, con := Context (optional). This parameter sets the scheme,
address and port at which this server is available in the form address and port at which this server is available in the form
scheme://host:port. Optional. In the absence of this scheme://host:port. Optional. In the absence of this
parameter the scheme of the protocol, source IP address and parameter the scheme of the protocol, source IP address and
source port used to register are assumed. This parameter is source port used to register are assumed. This parameter is
compulsory when the directory is filled by a third party such compulsory when the directory is filled by a third party such
as an installation tool. as an installation tool.
Content-Type: application/link-format (optional) Content-Format: application/link-format (optional)
Content-Type: application/link-format+json (optional) Content-Format: application/link-format+json (optional)
Content-Type: application/link-format+cbor (optional)
Content-Format: application/link-format+cbor (optional)
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.04 "Changed" or 204 "No Content" in the update was Success: 2.04 "Changed" or 204 "No Content" if the update was
successfully processed. successfully processed.
Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request. request.
Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not
exist (e.g. may have expired). exist (e.g. may have expired).
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.
skipping to change at page 23, line 8 skipping to change at page 23, line 31
endpoint with a configured default domain. The domain value is endpoint with a configured default domain. The domain value is
needed to export the endpoint to DNS-SD (see Section 9) needed to export the endpoint to DNS-SD (see Section 9)
con := Context (optional). This parameter is used to set the IP con := Context (optional). This parameter is used to set the IP
multicast address at which this server is available in the form multicast address at which this server is available in the form
scheme://multicast-address:port. Optional. In the absence of scheme://multicast-address:port. Optional. In the absence of
this parameter no multicast address is configured. This this parameter no multicast address is configured. This
parameter is compulsory when the directory is filled by an parameter is compulsory when the directory is filled by an
installation tool. installation tool.
Content-Type: application/link-format Content-Format: application/link-format
Content-Type: application/link-format+json Content-Format: application/link-format+json
Content-Type: application/link-format+cbor Content-Format: application/link-format+cbor
The following response codes are defined for this interface: The following response codes are defined for this interface:
Success: 2.01 "Created" or 201 "Created". The Location header MUST Success: 2.01 "Created" or 201 "Created". The Location header MUST
be included with the new group entry. This Location MUST be a be included with the new group entry. This Location MUST be a
stable identifier generated by the RD as it is used for delete stable identifier generated by the RD as it is used for delete
operations on this registration. operations on this registration.
Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed Failure: 4.00 "Bad Request" or 400 "Bad Request". Malformed
request. request.
skipping to change at page 26, line 9 skipping to change at page 26, line 28
URI Template: /{+rd-lookup-base}/{lookup- URI Template: /{+rd-lookup-base}/{lookup-
type}{?d,ep,gp,et,rt,page,count,resource-param} type}{?d,ep,gp,et,rt,page,count,resource-param}
URI Template Variables: URI Template Variables:
rd-lookup-base := RD Lookup Function Set path (mandatory). This rd-lookup-base := RD Lookup Function Set path (mandatory). This
is the path of the RD Lookup Function Set. An RD SHOULD use the is the path of the RD Lookup Function Set. An RD SHOULD use the
value "rd-lookup" for this variable whenever possible. value "rd-lookup" for this variable whenever possible.
Content-Format: application/link-format (optional)
Content-Format: application/link-format+json (optional)
Content-Format: application/link-format+cbor (optional)
lookup-type := ("d", "ep", "res", "gp") (mandatory) This variable lookup-type := ("d", "ep", "res", "gp") (mandatory) This variable
is used to select the kind of lookup to perform (domain, is used to select the kind of lookup to perform (domain,
endpoint, resource, or group). endpoint, resource, or group).
ep := Endpoint name (optional). Used for endpoint, group and ep := Endpoint name (optional). Used for endpoint, group and
resource lookups. resource lookups.
d := Domain (optional). Used for domain, group, endpoint and d := Domain (optional). Used for domain, group, endpoint and
resource lookups. resource lookups.
skipping to change at page 30, line 30 skipping to change at page 30, line 50
CoRE Resource Discovery is intended to support fine-grained discovery CoRE Resource Discovery is intended to support fine-grained discovery
of hosted resources, their attributes, and possibly other resource of hosted resources, their attributes, and possibly other resource
relations [RFC6690]. In contrast, service discovery generally refers relations [RFC6690]. In contrast, service discovery generally refers
to a coarse-grained resolution of an endpoint's IP address, port to a coarse-grained resolution of an endpoint's IP address, port
number, and protocol. number, and protocol.
Resource and service discovery are complementary in the case of large Resource and service discovery are complementary in the case of large
networks, where the latter can facilitate scaling. This document networks, where the latter can facilitate scaling. This document
defines a mapping between CoRE Link Format attributes and DNS-Based defines a mapping between CoRE Link Format attributes and DNS-Based
Service Discovery [RFC6763] fields that permits discovery of CoAP Service Discovery [RFC6763] fields that permits discovery of CoAP
services by either means. services by either method.
9.1. DNS-based Service discovery 9.1. DNS-based Service discovery
DNS-Based Service Discovery (DNS-SD) defines a conventional method of DNS-Based Service Discovery (DNS-SD) defines a conventional method of
configuring DNS PTR, SRV, and TXT resource records to facilitate configuring DNS PTR, SRV, and TXT resource records to facilitate
discovery of services (such as CoAP servers in a subdomain) using the discovery of services (such as CoAP servers in a subdomain) using the
existing DNS infrastructure. This section gives a brief overview of existing DNS infrastructure. This section gives a brief overview of
DNS-SD; see [RFC6763] for a detailed specification. DNS-SD; see [RFC6763] for a detailed specification.
DNS-SD service names are limited to 255 octets and are of the form: DNS-SD service names are limited to 255 octets and are of the form:
Service Name = <Instance>.<ServiceType>.<Domain>. Service Name = <Instance>.<ServiceType>.<Domain>.
The service name is the label of SRV/TXT resource records. The SRV The service name is the label of SRV/TXT resource records. The SRV
RR specifies the host and the port of the endpoint. The TXT RR RR specifies the host and the port of the endpoint. The TXT RR
provides additional information. provides additional information in the form of key/value pairs.
The <Domain> part of the service name is identical to the global (DNS The <Domain> part of the service name is identical to the global (DNS
subdomain) part of the authority in URIs that identify servers or subdomain) part of the authority in URIs that identify servers or
groups of servers. groups of servers.
The <ServiceType> part is composed of at least two labels. The first The <ServiceType> part is composed of at least two labels. The first
label of the pair is the application protocol name [RFC6335] preceded label of the pair is the application protocol name [RFC6335] preceded
by an underscore character. The second label indicates the transport by an underscore character. The second label indicates the transport
and is always "_udp" for UDP-based CoAP services. In cases where and is always "_udp" for UDP-based CoAP services. In cases where
narrowing the scope of the search may be useful, these labels may be narrowing the scope of the search may be useful, these labels may be
optionally preceded by a subtype name followed by the "_sub" label. optionally preceded by a subtype name followed by the "_sub" label.
An example of this more specific <ServiceType> is An example of this more specific <ServiceType> is
"lamp._sub._dali._udp". "light._sub._dali._udp".
The default <Instance> part of the service name may be set at the A default <Instance> part of the service name may be set at the
factory or during the commissioning process. It SHOULD uniquely factory or during the commissioning process. It SHOULD uniquely
identify an instance of <ServiceType> within a <Domain>. Taken identify an instance of <ServiceType> within a <Domain>. Taken
together, these three elements comprise a unique name for an SRV/ TXT together, these three elements comprise a unique name for an SRV/ TXT
record pair within the DNS subdomain. record pair within the DNS subdomain.
The granularity of a service name MAY be that of a host or group, or The granularity of a service name MAY be that of a host or group, or
it could represent a particular resource within a CoAP server. The it could represent a particular resource within a CoAP server. The
SRV record contains the host name (AAAA record name) and port of the SRV record contains the host name (AAAA record name) and port of the
service while protocol is part of the service name. In the case service while protocol is part of the service name. In the case
where a service name identifies a particular resource, the path part where a service name identifies a particular resource, the path part
skipping to change at page 40, line 12 skipping to change at page 40, line 43
registered. Because the presence sensor sends one multicast message registered. Because the presence sensor sends one multicast message
to the luminaries, all lamps in the group need to have an identical to the luminaries, all lamps in the group need to have an identical
path. This path is created on the two luminaries using the batch path. This path is created on the two luminaries using the batch
command defined in [I-D.ietf-core-interfaces]. The path to a batch command defined in [I-D.ietf-core-interfaces]. The path to a batch
of lamps is defined as: /light/grp1. In the example below, two of lamps is defined as: /light/grp1. In the example below, two
endpoints are updated with an additional resource using the path endpoints are updated with an additional resource using the path
/light/grp1 on the two luminaries. /light/grp1 on the two luminaries.
Req: POST Req: POST
coap://[FDFD::ABCD:1]/light/grp1 coap://[FDFD::ABCD:1]/light/grp1
(content-type:application/link-format)<light/middle>,<light/left> (Content-Format:application/link-format)<light/middle>,<light/left>
Res: 2.04 Changed Res: 2.04 Changed
Req: POST Req: POST
coap://[FDFD::ABCD:2]/light/grp1 coap://[FDFD::ABCD:2]/light/grp1
(content-type:application/link-format)<light/right> (Content-Format:application/link-format)<light/right>
Res: 2.04 Changed Res: 2.04 Changed
The group is specified in the RD. The Context parameter is set to The group is specified in the RD. The Context parameter is set to
the site-local multicast address allocated to the group. In the POST the site-local multicast address allocated to the group. In the POST
in the example below, these two end-points and the end-point of the in the example below, these two end-points and the end-point of the
presence sensor are registered as members of the group. presence sensor are registered as members of the group.
It is expected that Standards Developing Organizations (SDOs) may It is expected that Standards Developing Organizations (SDOs) may
develop other special purpose protocols to specify additional group develop other special purpose protocols to specify additional group
links, group membership, group names and other parameters in the links, group membership, group names and other parameters in the
individual nodes. individual nodes.
skipping to change at page 48, line 30 skipping to change at page 49, line 30
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 Section 5.4. registration proceeds as described in Section 5.4.
13. Acknowledgments 13. Acknowledgments
Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders Brandt,
Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided Matthieu Vial, Mohit Sethi, Sampo Ukkola and Linyi Tian have provided
helpful comments, discussions and ideas to improve and shape this helpful comments, discussions and ideas to improve and shape this
document. Zach would also like to thank his colleagues from the EU document. Section 9 is based on an earlier draft by Kerry Lynn.
FP7 SENSEI project, where many of the resource directory concepts Zach would also like to thank his colleagues from the EU FP7 SENSEI
were originally developed. project, where many of the resource directory concepts were
originally developed.
14. Changelog 14. Changelog
changes from -06 to -07
o added text in the discovery section to allow content format hints
to be exposed in the discovery link attributes
o editorial updates to section 9
o update author information
o minor text corrections
Changes from -05 to -06 Changes from -05 to -06
o added note that the PATCH section is contingent on the progress of o added note that the PATCH section is contingent on the progress of
the PATCH method the PATCH method
Changes from -04 to -05 changes from -04 to -05
o added Update Endpoint Links using PATCH o added Update Endpoint Links using PATCH
o http access made explicit in interface specification o http access made explicit in interface specification
o Added http examples o Added http examples
Changes from -03 to -04: Changes from -03 to -04:
o Added http response codes o Added http response codes
skipping to change at page 53, line 34 skipping to change at page 55, line 4
Authors' Addresses Authors' Addresses
Zach Shelby Zach Shelby
ARM ARM
150 Rose Orchard 150 Rose Orchard
San Jose 95134 San Jose 95134
USA USA
Phone: +1-408-203-9434 Phone: +1-408-203-9434
Email: zach.shelby@arm.com Email: zach.shelby@arm.com
Michael Koster Michael Koster
ARM SmartThings
150 Rose Orchard 665 Clyde Avenue
San Jose 95134 Mountain View 94043
USA USA
Phone: +1-408-576-1500 x11516 Phone: +1-707-502-5136
Email: Michael.Koster@arm.com Email: Michael.Koster@smartthings.com
Carsten Bormann Carsten Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
Postfach 330440 Postfach 330440
Bremen D-28359 Bremen D-28359
Germany Germany
Phone: +49-421-218-63921 Phone: +49-421-218-63921
Email: cabo@tzi.org Email: cabo@tzi.org
Peter van der Stok Peter van der Stok
 End of changes. 43 change blocks. 
86 lines changed or deleted 115 lines changed or added

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