< draft-ietf-core-rd-dns-sd-03.txt   draft-ietf-core-rd-dns-sd-04.txt >
CoRE K. Lynn CoRE K. Lynn
Internet-Draft Oracle + Dyn Internet-Draft Oracle+Dyn
Intended status: Standards Track P. van der Stok Intended status: Standards Track P. van der Stok
Expires: April 25, 2019 Consultant Expires: September 12, 2019 Consultant
M. Koster M. Koster
SmartThings SmartThings
C. Amsuess C. Amsuess
Energy Harvesting Solutions Energy Harvesting Solutions
October 22, 2018 March 11, 2019
CoRE Resource Directory: DNS-SD mapping CoRE Resource Directory: DNS-SD mapping
draft-ietf-core-rd-dns-sd-03 draft-ietf-core-rd-dns-sd-04
Abstract Abstract
Resource and service discovery are complimentary. Resource discovery Resource and service discovery are complementary. Resource discovery
provides fine-grained detail about the content of a server, while provides fine-grained detail about the content of a web server, while
service discovery can provide a scalable method to locate servers in service discovery can provide a scalable method to locate servers in
large networks. This document defines a method for mapping between large networks. This document defines a method for mapping between
CoRE Link Format attributes and DNS-Based Service Discovery fields to CoRE Link Format attributes and DNS-Based Service Discovery records
facilitate the use of either method to locate RESTful service to facilitate the use of either method to locate RESTful service
interfaces (APIs) in heterogeneous HTTP/CoAP environments. interfaces (APIs) in heterogeneous HTTP/CoAP environments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 25, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Background . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. CoRE Resource Discovery . . . . . . . . . . . . . . . . . 3 1.2. CoRE Resource Discovery . . . . . . . . . . . . . . . . . 4
1.3. CoRE Resource Directories . . . . . . . . . . . . . . . . 4 1.3. CoRE Resource Directories . . . . . . . . . . . . . . . . 5
1.4. DNS-Based Service Discovery . . . . . . . . . . . . . . . 5 1.4. DNS-Based Service Discovery . . . . . . . . . . . . . . . 5
2. Mapping from web resources DNS services . . . . . . . . . . . 6 2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 6
2.1. Domain mapping . . . . . . . . . . . . . . . . . . . . . 6 2.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7
2.2. ServiceType mapping . . . . . . . . . . . . . . . . . . . 6 2.2. Resource Instance attribute "ins=" . . . . . . . . . . . 7
2.3. Instance mapping . . . . . . . . . . . . . . . . . . . . 7 2.3. Service Type attribute "st=" . . . . . . . . . . . . . . 7
3. New Link-Format Attributes . . . . . . . . . . . . . . . . . 7 3. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 7
3.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7 3.1. Mapping Resource Instance attribute "ins=" to <Instance> 7
3.2. Resource Instance attribute "ins" . . . . . . . . . . . . 8 3.2. Mapping Service Type attribute "st=" to <ServiceType> . . 8
4. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 8 3.3. <Domain> Mapping . . . . . . . . . . . . . . . . . . . . 8
4.1. Mapping Resource Instance attribute "ins" to <Instance> . 8 3.4. TXT Record key=value strings . . . . . . . . . . . . . . 9
4.2. Mapping Resource Type attribute "rt" to <ServiceType> . . 9 3.5. Exporting resource links into DNS-SD . . . . . . . . . . 9
4.3. TXT Record key=value strings . . . . . . . . . . . . . . 9 4. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10
4.4. Exporting resource links into DNS-SD . . . . . . . . . . 10 5. Security considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Mapping Resource Type into ServiceType . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
6. Security considerations . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 11
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction and Background
The Constrained RESTful Environments (CoRE) working group aims at The Constrained RESTful Environments (CoRE) working group aims at
realizing the REST architecture in a suitable form for the most realizing the [REST] architecture in a suitable form for the most
constrained devices (e.g. 8-bit microcontrollers with limited RAM and constrained devices (e.g. 8-bit microcontrollers with limited RAM and
ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- ROM) and networks (e.g. 6LoWPAN [RFC4944]). CoRE is aimed at
machine (M2M) applications such as smart energy and building machine-to-machine (M2M) applications such as smart energy and
automation. The main deliverable of CoRE is the Constrained building automation. The main deliverable of CoRE is the Constrained
Application Protocol (CoAP) specification [RFC7252]. Application Protocol (CoAP) specification [RFC7252].
Automated discovery of resources hosted by a constrained server is CoRE Link Format [RFC6690] is intended to support fine-grained
critical in M2M applications where human intervention is minimal and discovery of hosted resources, their attributes, and possibly other
static interfaces result in brittleness. CoRE Resource Discovery is related resources. Automated dynamic discovery of resources hosted
intended to support fine-grained discovery of hosted resources, their by a constrained server is critical in M2M applications, where human
attributes, and possibly other resource relations [RFC6690]. intervention is minimal and static configurations result in
brittleness.
In contrast to resource discovery, service discovery generally refers DNS-Based Service Discovery (DNS-SD) [RFC6763] supports wide-area
to a coarser-grained resolution of an endpoint's IP address, port search for instances of a given service type (i.e. servers that
number, and protocol. This definition may be extended to include support a particular application protocol stack). A service instance
multi-function devices, where the result of the discovery process may consists of a server's name, IP address, and port number plus
include a path to a resource representing a RESTful service interface additional meta-data about the server. This data may extend to
and possibly a reference to a description of the interface such as a support multi-function devices, where multiple services are available
JSON Hyper-Schema document [I-D.handrews-json-schema-hyperschema] per at the same endpoint. The result of the discovery process may
function. include a path to a resource representing the entry point to each
function's RESTful service interface and possibly a link to a formal
description of that interface (e.g. a JSON Hyper-Schema document
[I-D.handrews-json-schema-hyperschema]).
Resource and service discovery are complimentary 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 (DNS-SD) [RFC6763] fields that permits discovery of Service Discovery records that permits discovery of CoAP services by
CoAP services by either method. It also addresses the CoRE charter either method. It also addresses the CoRE charter goal to
goal to interoperate with DNS-SD. interoperate with DNS-SD.
The actual publishing of DNS services on the basis of the contents of The primary use case for mapping between resource and service
the Resource Directory is the subject of discovery is to support heterogeneous HTTP/CoAP environments where,
[I-D.sctl-service-registration]. for example, HTTP clients may discover and communicate with CoAP
servers that are behind a "cross proxy" [RFC8075].
1.1. Terminology 1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. The term "byte" is used in its now conventional sense as [RFC2119]. The term "byte" is used in its now conventional sense as
a synonym for "octet". a synonym for "octet".
This specification requires readers to be familiar with all the terms This specification requires readers to be familiar with all the terms
and concepts that are discussed in [RFC6690] and [RFC8288]. Readers and concepts that are discussed in [RFC6690] and [RFC8288]. Readers
should also be familiar with the terms and concepts discussed in should also be familiar with the terms and concepts discussed in
[RFC7252]. To describe the REST interfaces defined in this [RFC7252].
specification, the URI Template format is used [RFC6570].
This specification also incorporates the terminology of This specification also incorporates the terminology of
[I-D.ietf-core-resource-directory]. [I-D.ietf-core-resource-directory].
1.2. CoRE Resource Discovery In particular, the following terms are used frequently:
[RFC8288] defines a Web Link (link) as a typed connection between two Endpoint: a web server associated with a specific IP address and
resources, comprised of: port; thus a physical device may host one or more endpoints.
Endpoints may also act as clients.
Link: Web Linking [RFC8288] defines a Web Link (link) as a typed
connection between two resources, comprised of:
o a link context, o a link context,
o a link relation type (see Section 2.1 of [RFC8288], o a link relation type (see Section 2.1 of [RFC8288],
o a link target, and o a link target, and
o optionally, target attributes (see Section 2.2 of [RFC8288]). o optionally, target attributes (see Section 2.2 of [RFC8288]).
A link can be viewed as a statement of the form "link context has a A link can be viewed as a statement of the form "link context has a
link relation type resource at link target, which (optionally) has link relation type resource at link target, which (optionally) has
target attributes", where link target (and context) is typically a target attributes", where link target and context are typically
Universal Resource Identifier (URI) [RFC3986]. Universal Resource Identifiers (URIs) [RFC3986]. For example,
"https://www.example.com/" has a "canonical" resource at
For example, "https://www.example.com/" has a "canonical" resource at
"https://example.com", which has a "type" of "text/html". "https://example.com", which has a "type" of "text/html".
1.2. CoRE Resource Discovery
The main function of Resource Discovery is to return links to the The main function of Resource Discovery is to return links to the
resources hosted by a server, complemented by attributes about those resources hosted by a server, complemented by attributes about those
resources and additional link relations. In CoRE this collection of resources and additional link relations. In CoRE this collection of
links and attributes is itself a resource (as opposed to HTTP headers links and attributes is itself a resource (in contrast to HTTP, where
delivered with a specific resource). headers delivered with a specific resource describe its attributes).
[RFC6690] specifies a link format for use in CoRE Resource Discovery
by extending the HTTP Link Header Format [RFC8288] to describe these
link descriptions. The CoRE Link Format is carried as a payload and
is serialized according to one of several Internet media types. CoRE
Resource Discovery is accomplished by sending a GET request to the
well-known URI "/.well- known/core", which is defined as a default
entry-point for requesting the collection of links to resources
hosted by a server.
Resource Discovery can be performed either via unicast or multicast. Resource Discovery can be performed either unicast or multicast.
When a server's IP address is already known, either a priori or When a server's IP address is already known, either a priori or
resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast
discovery is performed in order to locate a URI for the resource of discovery is performed in order to locate the entry point to the
interest. This is performed using a GET to /.well-known/core on the resource of interest. This is performed using a GET to "/.well-
server, which returns the links. A client would then match the known/core" on the server, which returns a payload in the CoRE Link
appropriate Resource Type, Interface Description, and possible Format [RFC6690]. A client would then match the appropriate Resource
Content-Type [RFC2045] for its application. These attributes may Type, Interface Description, and possible media type [RFC2045] for
also be included in the query string in order to filter the number of its application. These attributes may also be included in the query
links returned in a response. string in order to filter the number of links returned in a response.
Multicast Resource Discovery is useful when a client needs to locate
a resource within a limited scope, and that scope supports IP
multicast. A GET request to the appropriate multicast address is
made for "/.well-known/core". In order to limit the number and size
of responses, a query string is recommended with the known
attributes. Typically, a resource would be discovered based on its
Resource Type and/or Interface Description, along with possible
application-specific attributes.
1.3. CoRE Resource Directories 1.3. CoRE Resource Directories
In many M2M scenarios, direct discovery of resources is not practical In many M2M scenarios, direct discovery of resources is not practical
due to sleeping nodes, limited bandwidth, or networks where multicast due to sleeping nodes, limited bandwidth, or networks where multicast
traffic is inefficient. These problems can be solved by deploying a traffic is inefficient. These problems can be solved by deploying a
network element called a Resource Directory (RD), which hosts network element called a Resource Directory (RD), which hosts
descriptions of resources held on other servers (referred to as "end- descriptions of resources that originate on other endpoints and
points") and allows lookups to be performed for those resources. An allows indirect lookups to be performed for those resources.
endpoint is a web server associated with a specific IP address and
port; thus a physical device may host one or more endpoints. End-
points may also act as clients.
The Resource Directory implements a set of REST interfaces for end- The Resource Directory implements a set of REST interfaces for
points to register and maintain collections of links, called resource endpoints to register and maintain collections of links, called
directory registrations. [I-D.ietf-core-resource-directory] Resource Directory registrations. [I-D.ietf-core-resource-directory]
specifies the web interfaces that an RD supports for endpoints to specifies the web interfaces that an RD supports for endpoints to
discover the RD and to register, maintain, lookup and remove resource discover the RD and to register, maintain, lookup and remove resource
descriptions; for the RD to validate entries; and for clients to descriptions; for the RD to validate entries; and for clients to
lookup resources from the RD. lookup resources from the RD.
1.4. DNS-Based Service Discovery 1.4. 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
naming and configuring DNS PTR, SRV, and TXT resource records to naming and configuring DNS PTR, SRV, and TXT resource records to
facilitate discovery of services (such as CoAP servers in a facilitate discovery of services (such as CoAP servers in a
subdomain) using the existing DNS infrastructure. This section gives subdomain) using the existing DNS infrastructure. This section gives
a brief overview of DNS-SD; for a detailed specification see a brief overview of DNS-SD; for a detailed specification see
[RFC6763]. [RFC6763].
DNS-SD Service Names are limited to 255 bytes and are of the form: DNS-SD Service Names are limited to 255 bytes and are of the form:
Service Name = <Instance>.<ServiceType>.<Domain> Service Name = <Instance>.<ServiceType>.<Domain>
The Service Name identifies a SRV/TXT resource record (RR) pair. The The Service Name identifies a SRV/TXT resource record (RR) pair. The
SRV RR specifies the host and port of an endpoint. The TXT RR SRV RR specifies the hostname and port of an endpoint. The TXT RR
provides additional information in the form of key/value pairs. DNS- provides additional information in the form of key/value pairs. DNS-
Based Service Discovery is accomplished by sending a DNS request for Based Service Discovery is accomplished by sending a DNS request for
PTR records with the name <ServiceType>.<Domain>, which will return a PTR records with the name <ServiceType>.<Domain>, which will return a
list of zero or more Service Names. list of zero or more Service Names.
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 the resources subdomain) part of the authority in URIs [RFC3986] that identify the
on an individual server or group of servers. resources on an individual server or group of servers.
The <ServiceType> part is composed of at least two labels. The first The <ServiceType> part is generally composed of two labels. The
label of the pair is the application protocol name [RFC6335] preceded first label of the pair is the application protocol name [RFC6335]
by an underscore character. For example, an organization such as the preceded by an underscore character. For example, an organization
Open Connectivity Foundation [OCF] that specifies resources might such as the Open Connectivity Foundation [OCF] that specifies
register the application protocol name "_oic", which all servers that Resource Types [RFC6335] might register application protocol names
advertise OCF resources would use as part of their ServiceType. The beginning with "oic", which all servers that advertise OCF resources
second label indicates the transport and is typically "_udp" for CoAP would use as part of their ServiceType. The second label indicates
services. In cases where narrowing the scope of the search may be the transport protocol binding and is typically "_udp" for CoAP
useful, these labels may be optionally preceded by a subtype name services.
followed by the "_sub" label. An example of this more specific
<ServiceType> is "light._sub._oic._udp".
The default <Instance> part of the Service Name SHOULD be set to a The default <Instance> part of the Service Name SHOULD be set to a
default value at the factory and MAY be modified during the default value at the factory and MAY be modified during the
commissioning process. It MUST uniquely identify an instance of commissioning process. It MUST uniquely identify an instance of
<ServiceType> within a <Domain>. Taken together, these three <ServiceType> within a <Domain>. Taken together, these three
elements comprise a unique name for an SRV/TXT record pair within the elements comprise a unique name for an SRV/TXT record pair within the
DNS subdomain. 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 might represent a particular resource within a CoAP server. The it might 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
endpoint while protocol is part of the Service Name. In the case endpoint, 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
of the URI must be carried in a corresponding TXT record. of the URI must be carried in a corresponding TXT record.
A DNS TXT record is in practice limited to a few hundred bytes in A DNS TXT record is in practice limited to a few hundred bytes in
length, which is indicated in the resource record header in the DNS length, which is indicated in the resource record header in the DNS
response message [RFC6763]. The data consists of one or more strings response message (See section 6 of [RFC6763]). The data consist of
comprising a key/value pair. By convention, the first pair is one or more strings comprising a key/value pair. By convention, the
txtver=<number> (to support different versions of a service first pair is txtver=<number> (to support different versions of a
description). An example string is: service description). Each string is formatted as a single length
byte followed by 0-255 bytes of text. An example string is:
---------------------------------------- ----------------------------------------
| 0x08 | t | x | t | v | e | r | = | 1 | | 0x08 | t | x | t | v | e | r | = | 1 |
---------------------------------------- ----------------------------------------
2. Mapping from web resources DNS services 2. New Link-Format Attributes
These sections describe how each of the three parts of the Service
Name can be mapped to link attributes.
2.1. Domain mapping
TBD: A method must be specified to determine in which DNS zone the
CoAP service should be registered. See, for example, Section 11 in
[RFC6763] and Section 2 in [I-D.sctl-service-registration]
2.2. ServiceType mapping
ServiceTypes are registered by IANA [st]. They identify services
that can be specified by IETF or any other Standards Development
Organization (SDO). The IANA resource type registry [rt] is based on
the resource type (rt= attribute) [RFC6690] which identifies endpoint
functionality specified by IETF or any other SDO.
It is expected that an endpoint providing a given ServiceType
represents a collection of resources each with its own Resource Type.
The Resource Type of the collection MUST be mapped directly to the
ServiceType. A registry is required to specify the mapping between
Resource Types and ServiceTypes.
2.3. Instance mapping
The Instance name may be freely chosen by the manufacturer and
inserted in the device. During installation the pre-configured
Instance name can be pre- or post-fixed with a string to make the
(Instance, ServiceType) pair unique within the domain. For manual
discovery it is useful when the Instance name is a human readable
string containing the manufacturer name or the device type.
IoT devices are not necessarily equipped with an Instance name for
DNS-SD. To make the (Instance, ServiceType) pair unique, it is
sufficient to use another unique identifier stored in the device such
as the Public key or UUID of the device. When a human readable name
is required, the interface description (if= attribute) [RFC6690] may
provide for example, a URN that can be made unique by pre- or post-
fixing it with a string as is currently done for the Instance name
devices conforming to DNS-SD specification.
When the device selects the Instance name, the device, registering
with the RD, MUST provide an Instance name in its link. When a third
party device, the Commissioning Tool (CT)
[I-D.ietf-core-resource-directory], selects the Instance name, it
specifies the Instance name when registering the device with the
Resource Directory.
3. New Link-Format Attributes
When using the CoRE Link Format to describe resources being When using the CoRE Link Format to describe resources being
discovered by or posted to a resource directory service, additional discovered by or posted to a resource directory service, additional
information about those resources is useful. This specification information about those resources is often useful. This
defines the following new attributes for use in the CoRE Link Format specification defines the following new attributes for use in the
[RFC6690]: CoRE Link Format [RFC6690] to enable the data-driven mappings
described in Section 3:
link-extension = ( "exp" ) link-extension = ( "exp" )
link-extension = ( "ins" "=" (ptoken | quoted-string) ) link-extension = ( "ins" "=" (ptoken | quoted-string) )
; The token or string is max 63 bytes ; The token or string is max 63 bytes
link-extension = ( "st" "=" (ptoken | quoted-string) )
; The token or string is max 15 bytes
3.1. Export attribute "exp" 2.1. Export attribute "exp"
The Export "exp" attribute is used as a flag to indicate that a link The Export "exp" attribute is used as a flag to indicate that a link
description MAY be exported from a resource directory to external description MAY be exported from a resource directory to external
directories. directories.
The CoRE Link Format is used for many purposes between CoAP The CoRE Link Format is used for many purposes between CoAP
endpoints. Some are useful mainly locally; for example checking the endpoints. Some are useful mainly locally; for example checking the
observability of a resource before accessing it, determining the size observability of a resource before accessing it, determining the size
of a resource, or traversing dynamic resource structures. However, of a resource, or traversing dynamic resource structures. However,
other links are very useful to be exported to other directories, for other links are very useful to be exported to other directories, for
example the entry point resource to a functional service. This example the entry point resource to a functional service. This
attribute MAY be used as a query parameter in the RD Lookup Function attribute MAY be used as a query parameter in the RD Lookup Function
Set defined in Section 7 of [I-D.ietf-core-resource-directory]. Set defined in Section 7 of [I-D.ietf-core-resource-directory].
3.2. Resource Instance attribute "ins" 2.2. Resource Instance attribute "ins="
The Resource Instance "ins" attribute is an identifier for this The Resource Instance "ins=" attribute is an identifier for this
resource, which makes it possible to distinguish it from other resource, which makes it possible to distinguish it from other
similar resources. This attribute is equivalent in use to the similar resources in a Resource Directory. This attribute specifies
<Instance> portion of a DNS-SD record (see Section 1.4), and SHOULD the value to be used for the <Instance> portion of an exported DNS-SD
be unique across resources with the same Resource Type attribute in Service Name (see Section 1.4), and SHOULD be unique across resources
the domain in which it is used. A Resource Instance SHOULD be a with the same Resource Type "rt=" attribute in the domain in which it
descriptive string like "Ceiling Light, Room 3", but MAY be a short is used.
ID like "AF39", a unique UUID, or fingerprint of a public key. This
attribute is used by a Resource Directory to distinguish between
multiple instances of the same resource type within the directory.
This attribute MUST NOT be more than 63 bytes in length. The A Resource Instance SHOULD be a descriptive human readable string
resource identifier attribute MUST NOT appear more than once in a like "Ceiling Light, Room 3". This attribute MUST NOT be more than
link description. This attribute MAY be used as a query parameter in 63 bytes in length. The resource identifier attribute MUST NOT
the RD Lookup Function Set defined in Section 7 of appear more than once in a link description. This attribute MAY be
[I-D.ietf-core-resource-directory]. used as a query parameter in the RD Lookup Function Set defined in
Section 7 of [I-D.ietf-core-resource-directory].
4. Mapping CoRE Link Attributes to DNS-SD Record Fields 2.3. Service Type attribute "st="
4.1. Mapping Resource Instance attribute "ins" to <Instance> The Service Type instance "st=" attribute specifies the value to be
used for the <ServiceType> portion of an exported DNS-SD Service Name
(see Section 1.4). This attribute MUST NOT be more than 15 bytes in
length (see [RFC6335], Section 5.1) and MUST be present in the IANA
Service Name registry [st].
The Resource Instance "ins" attribute maps to the <Instance> part of 3. Mapping CoRE Link Attributes to DNS-SD Record Fields
a DNS-SD Service Name. It is stored directly in the DNS as a single
DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 3.1. Mapping Resource Instance attribute "ins=" to <Instance>
(Unicode Normalization Form C) [RFC5198] text. However, if the "ins"
attribute is chosen to match the DNS host name of a service, it The Resource Instance "ins=" attribute maps directly to the
SHOULD use the syntax defined in Section 3.5 of [RFC1034] and <Instance> part of a DNS-SD Service Name. It is stored directly in
Section 2.1 of [RFC1123]. the DNS as a single DNS label of canonical precomposed UTF-8
[RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198]
text. However, if the "ins=" attribute is chosen to match the DNS
host name of a service, it SHOULD use the syntax defined in
Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123].
The <Instance> part of the name of a service being offered on the The <Instance> part of the name of a service being offered on the
network SHOULD be configurable by the user setting up the service, so network SHOULD be configurable by the user setting up the service, so
that he or she may give it an informative name. However, the device that he or she may give it an informative name. However, the device
or service SHOULD NOT require the user to configure a name before it or service SHOULD NOT require the user to configure a name before it
can be used. A sensible choice of default name can allow the device can be used. A sensible choice of default name can allow the device
or service to be accessed in many cases without any manual or service to be accessed in many cases without any manual
configuration at all (see Appendix D of [RFC6763]). configuration at all (see Appendix D of [RFC6763]).
DNS labels are limited to 63 bytes in length and the entire Service DNS labels are limited to 63 bytes in length and the entire Service
Name may not exceed 255 bytes. Name may not exceed 255 bytes.
4.2. Mapping Resource Type attribute "rt" to <ServiceType> 3.2. Mapping Service Type attribute "st=" to <ServiceType>
The <ServiceType> part of a DNS-SD Service Name is derived from the
"rt" attribute and SHOULD conform to the reg-rel-type production of
the Link Format defined in Section 2 of [RFC6690].
In practice, the ServiceType should unambiguously identify inter- The Service Type "st=" attribute maps directly to the <ServiceType>
operable devices. It is up to individual SDOs to specify how to map part of a DNS-SD Service Name.
between their registered Resource Type (rt=) values and ServiceType
values. Two approaches are possible; either a hierachical approach
as in Section 1.4 above, or a flat identifier. Both approaches are
shown below for illustration, but in practice only ONE would be
specified.
In either case, the resulting application protocol name MUST be In practice, the ServiceType should unambiguously identify
composed of at least a single Net-Unicode text string, without interoperable devices. It is up to individual SDOs to specify how to
underscore '_' or or period '.' and limited to 15 bytes in length represent their registered Resource Type "rt=" values as registered
(see Section 5.1 of [RFC6335]). This string is mapped to the DNS-SD application protocol names according to [RFC6335]. The application
<ServiceType> by prepending an underscore and appending a period name is then used as the value of the resource "st=" attribute.
followed by the "_udp" label. For example, rt="oic.d.light" might be
mapped into "_oic-d-light._udp".
The application protocol name may be optionally followed by a period The resulting application protocol name MUST be composed of at least
and a service subtype name consisting of a Net-Unicode text string, a single Net-Unicode text string, without underscore '_' or period
without underscore or period and limited to 63 bytes. This string is '.' and limited to 15 bytes in length (see Section 5.1 of [RFC6335]).
mapped to the DNS-SD <ServiceType> by appending a period followed by This string is mapped to the DNS-SD <ServiceType> by prepending an
the "_sub" label and then appending a period followed by the service underscore and appending a period followed by the "_udp" label. For
type label pair derived as in the previous paragraph. For example, example, rt="oic.d.light" might correspond to the registered
rt="oic.d.light" might be mapped into "light._sub._oic._udp". application protocol name st="oic-d-light" and would be mapped into
Service Type "_oic-d-light._udp".
The resulting string is used to form labels for DNS-SD records which The resulting string is used to form labels for DNS-SD records which
are stored directly in the DNS. are stored directly in the DNS.
4.3. TXT Record key=value strings 3.3. <Domain> Mapping
A number of [RFC6763] key/value pairs are derived from link-format TBD: A method must be specified to determine which DNS zone the CoAP
information, to be exported in the DNS-SD as key=value strings in a service description should be exported to. See, for example,
TXT record (See Section 6.3 of [RFC6763]). Section 11 in [RFC6763] and Section 2 in
[I-D.sctl-service-registration].
3.4. TXT Record key=value strings
DNS-SD key/value pairs may be derived from CoRE Link Format
information and exported as key=value strings in a DNS-SD TXT record
(See Section 6.3 of [RFC6763]).
The resource <URI> is exported as key/value pair "path=<URI>". The resource <URI> is exported as key/value pair "path=<URI>".
The Interface Description "if" attribute is exported as key/value The Interface Description "if=" attribute is exported as key/value
pair "if=<Interface Description>". pair "if=<Interface Description>".
The DNS TXT record can be further populated by importing any other The DNS TXT record can be further populated by importing any other
resource description attributes as they share the same key=value resource description attributes as they share the same key=value
format specified in Section 6 of [RFC6763]. format specified in Section 6 of [RFC6763].
4.4. Exporting resource links into DNS-SD 3.5. Exporting resource links into DNS-SD
Assuming the ability to query a Resource Directory or multicast a GET Assuming the ability to query a Resource Directory or multicast a GET
(?exp) over the local link, CoAP resource discovery may be used to (?exp) over the local link, CoAP resource discovery may be used to
populate the DNS-SD database in an automated fashion. CoAP resource populate the DNS-SD database in an automated fashion. CoAP resource
descriptions (links) can be exported to DNS-SD for exposure to descriptions (links) can be exported to DNS-SD for exposure to
service discovery by using the Resource Instance attribute as the service discovery by using the Resource Instance attribute as the
basis for a unique Service Name, composed with the Resource Type as basis for a unique Service Name, composed with the Service Type
the <ServiceType>, and registered in the correct <Domain>. The agent attribute as the <ServiceType>, and registered in the appropriate
responsible for exporting records to the DNS zone file SHOULD be <Domain>. The agent responsible for exporting records to the DNS
authenticated to the DNS server. The following example, using the zone file SHOULD be authenticated to the DNS server. The following
example lookup location /rd-lookup, shows an agent discovering a example, using the example lookup location /rd-lookup, shows an agent
resource to be exported: discovering a resource to be exported:
Req: GET /rd-lookup/res?exp Req: GET /rd-lookup/res?exp
Res: 2.05 Content Res: 2.05 Content
<coap://[FDFD::1234]:5683/light/1>; <coap://[FDFD::1234]:5683/light/1>;
exp;rt="oic.d.light";ins="Spot"; exp;st=oic-d-light;rt="oic.d.light";ins="Spot";
d="office";ep="node1" d="office";ep="node1"
The agent subsequently registers the following DNS-SD RRs, assuming a The agent subsequently registers the following DNS-SD RRs, assuming a
zone name "example.com" prefixed with "office": derived DNS zone name "office.example.com":
_oic._udp.office.example.com IN PTR
Spot._oic._udp.office.example.com
light._sub._oic._udp.example.com IN PTR
Spot._oic._udp.office.example.com
Spot._oic._udp.office.example.com IN TXT
txtver=1;path=/light/1
Spot._oic._udp.office.example.com IN SRV 0 0 5683
node1.office.example.com.
node1.office.example.com. IN AAAA FDFD::1234
In the above figure the Service Name is chosen as _oic-d-light._udp.office.example.com IN PTR
Spot._oic._udp.office.example.com without the light._sub service Spot._oic-d-light._udp.office.example.com
prefix. An alternative Service Name would be: Spot._oic-d-light._udp.office.example.com IN TXT
Spot.light._sub._oic._udp.office.example.com. txtver=1;path=/light/1;rt=oic.d.light
Spot._oic-d-light._udp.office.example.com IN SRV 0 0 5683
node1.office.example.com.
node1.office.example.com. IN AAAA FDFD::1234
5. IANA considerations 4. IANA considerations
5.1. Mapping Resource Type into ServiceType This specification defines new parameters for the registry "RD
Parameters" provided under "CoRE Parameters" (TBD).
TBD +----------------+-------+---------------+-----+--------------------+
| Full name | Short | Validity | Use | Description |
+----------------+-------+---------------+-----+--------------------+
| ServiceType | st | | RLA | Name of the |
| | | | |Service Type, |
| | | | | max 63 bytes |
| Resource | ins | | RLA | Instance identifier|
| Instance | | | | of the resource |
| | | | | |
| Export | exp | | RLA | flag to indicate |
| | | | | exportation |
+----------------+-------+---------------+-----+--------------------+
6. Security considerations 5. Security considerations
TBD TBD
7. References 6. References
7.1. Normative References 6.1. Normative References
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
skipping to change at page 11, line 41 skipping to change at page 11, line 14
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>.
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network
Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008,
<https://www.rfc-editor.org/info/rfc5198>. <https://www.rfc-editor.org/info/rfc5198>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA) Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Service Name and Procedures for the Management of the Service Name and
Transport Protocol Port Number Registry", BCP 165, Transport Protocol Port Number Registry", BCP 165,
RFC 6335, DOI 10.17487/RFC6335, August 2011, RFC 6335, DOI 10.17487/RFC6335, August 2011,
<https://www.rfc-editor.org/info/rfc6335>. <https://www.rfc-editor.org/info/rfc6335>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012,
<https://www.rfc-editor.org/info/rfc6570>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[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>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and
E. Dijk, "Guidelines for Mapping Implementations: HTTP to
the Constrained Application Protocol (CoAP)", RFC 8075,
DOI 10.17487/RFC8075, February 2017,
<https://www.rfc-editor.org/info/rfc8075>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
7.2. Informative References 6.2. Informative References
[I-D.handrews-json-schema-hyperschema] [I-D.handrews-json-schema-hyperschema]
Andrews, H. and A. Wright, "JSON Hyper-Schema: A Andrews, H. and A. Wright, "JSON Hyper-Schema: A
Vocabulary for Hypermedia Annotation of JSON", draft- Vocabulary for Hypermedia Annotation of JSON", draft-
handrews-json-schema-hyperschema-01 (work in progress), handrews-json-schema-hyperschema-01 (work in progress),
January 2018. January 2018.
[I-D.ietf-core-resource-directory] [I-D.ietf-core-resource-directory]
Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. Shelby, Z., Koster, M., Bormann, C., Stok, P., and C.
Amsuess, "CoRE Resource Directory", draft-ietf-core- Amsuess, "CoRE Resource Directory", draft-ietf-core-
resource-directory-15 (work in progress), October 2018. resource-directory-19 (work in progress), January 2019.
[I-D.sctl-service-registration] [I-D.sctl-service-registration]
Cheshire, S. and T. Lemon, "Service Registration Protocol Cheshire, S. and T. Lemon, "Service Registration Protocol
for DNS-Based Service Discovery", draft-sctl-service- for DNS-Based Service Discovery", draft-sctl-service-
registration-02 (work in progress), July 2018. registration-02 (work in progress), July 2018.
[OCF] Open Connectivity Foundation, "OCF Specification 2.0", [OCF] Open Connectivity Foundation, "OCF Specification 2.0",
2018, <https://openconnectivity.org/developer/ 2018, <https://openconnectivity.org/developer/
specifications>. specifications>.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Ph.D. Dissertation,
University of California, Irvine, 2000,
<http://www.ics.uci.edu/~fielding/pubs/dissertation/
fielding_dissertation.pdf>.
[rt] IANA, "Resource Type (rt=) Link Target Attribute [rt] IANA, "Resource Type (rt=) Link Target Attribute
Values", 2012, <https://www.iana.org/assignments/core- Values", 2012, <https://www.iana.org/assignments/core-
parameters/ parameters/
core-parameters.xhtml#rt-link-target-att-value>. core-parameters.xhtml#rt-link-target-att-value>.
[st] IANA, "Service Name and Transport Protocol Port Number [st] IANA, "Service Name and Transport Protocol Port Number
Registry", 2018, <https://www.iana.org/assignments/ Registry", 2018, <https://www.iana.org/assignments/
service-names-port-numbers/ service-names-port-numbers/
service-names-port-numbers.xml>. service-names-port-numbers.xml>.
Appendix A. Acknowledgments Appendix A. Acknowledgments
This document was split out from [I-D.ietf-core-resource-directory]. This document was split out from [I-D.ietf-core-resource-directory].
Zach Shelby was a co-author of the original version of this draft. Zach Shelby was a co-author of the original version of this draft.
The authors wish to thank Stuart Cheshire, Ted Lemon, and David
Thaler for their thorough reviews and clarifying suggestions.
Authors' Addresses Authors' Addresses
Kerry Lynn Kerry Lynn
Oracle + Dyn Oracle+Dyn
150 Dow Street, Tower Two 150 Dow Street, Tower Two
Manchester, NH 03101 Manchester, NH 03101
USA USA
Phone: +1 978-460-4253 Phone: +1 978-460-4253
Email: kerlyn@ieee.org Email: kerlyn@ieee.org
Peter van der Stok Peter van der Stok
Consultant Consultant
 End of changes. 72 change blocks. 
259 lines changed or deleted 238 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/