idnits 2.17.1 draft-ietf-core-rd-dns-sd-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 07, 2019) is 1753 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-02) exists of draft-handrews-json-schema-hyperschema-01 == Outdated reference: A later version (-46) exists of draft-ietf-ace-oauth-authz-24 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-22 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE P. van der Stok 3 Internet-Draft Consultant 4 Intended status: Standards Track M. Koster 5 Expires: January 8, 2020 SmartThings 6 C. Amsuess 7 Energy Harvesting Solutions 8 July 07, 2019 10 CoRE Resource Directory: DNS-SD mapping 11 draft-ietf-core-rd-dns-sd-05 13 Abstract 15 Resource and service discovery are complementary. Resource discovery 16 provides fine-grained detail about the content of a web server, while 17 service discovery can provide a scalable method to locate servers in 18 large networks. This document defines a method for mapping between 19 CoRE Link Format attributes and DNS-Based Service Discovery records 20 to facilitate the use of either method to locate RESTful service 21 interfaces (APIs) in heterogeneous HTTP/CoAP environments. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at https://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 8, 2020. 40 Copyright Notice 42 Copyright (c) 2019 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (https://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction and Background . . . . . . . . . . . . . . . . . 2 58 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.2. CoRE Resource Discovery . . . . . . . . . . . . . . . . . 4 60 1.3. CoRE Resource Directories . . . . . . . . . . . . . . . . 5 61 1.4. DNS-Based Service Discovery . . . . . . . . . . . . . . . 5 62 2. New Link-Format Attributes . . . . . . . . . . . . . . . . . 6 63 2.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7 64 2.2. Resource Instance attribute "ins=" . . . . . . . . . . . 7 65 2.3. Service Type attribute "st=" . . . . . . . . . . . . . . 7 66 3. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 7 67 3.1. Mapping Resource Instance attribute "ins=" to 7 68 3.2. Mapping Service Type attribute "st=" to . . 8 69 3.3. Mapping . . . . . . . . . . . . . . . . . . . . 8 70 3.4. TXT Record key=value strings . . . . . . . . . . . . . . 9 71 3.5. Exporting resource links into DNS-SD . . . . . . . . . . 9 72 4. Exporting Resource Directory Service to DNS . . . . . . . . . 10 73 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 74 5.1. RD Parameters Registry . . . . . . . . . . . . . . . . . 10 75 5.2. Service Name and Transport Protocol Port Number Registry 11 76 6. Security considerations . . . . . . . . . . . . . . . . . . . 11 77 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 9.2. Informative References . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction and Background 86 The Constrained RESTful Environments (CoRE) working group aims at 87 realizing the [REST] architecture in a suitable form for the most 88 constrained devices (e.g. 8-bit microcontrollers with limited RAM and 89 ROM) and networks (e.g. 6LoWPAN [RFC4944]). CoRE is aimed at 90 machine-to-machine (M2M) applications such as smart energy and 91 building automation. The main deliverable of CoRE is the Constrained 92 Application Protocol (CoAP) specification [RFC7252]. 94 CoRE Link Format [RFC6690] is intended to support fine-grained 95 discovery of hosted resources, their attributes, and possibly other 96 related resources. Automated dynamic discovery of resources hosted 97 by a constrained server is critical in M2M applications, where human 98 intervention is minimal and static configurations result in 99 brittleness. 101 DNS-Based Service Discovery (DNS-SD) [RFC6763] supports wide-area 102 search for instances of a given service type (i.e. servers that 103 support a particular application protocol stack). A service instance 104 consists of a server's name, IP address, and port number plus 105 additional meta-data about the server. This data may extend to 106 support multi-function devices, where multiple services are available 107 at the same endpoint. The result of the discovery process may 108 include a path to a resource representing the entry point to each 109 function's RESTful service interface and possibly a link to a formal 110 description of that interface (e.g. a JSON Hyper-Schema document 111 [I-D.handrews-json-schema-hyperschema]). 113 Resource and service discovery are complementary in the case of large 114 networks, where the latter can facilitate scaling. This document 115 defines a mapping between CoRE Link Format attributes and DNS-Based 116 Service Discovery records that permits discovery of CoAP services by 117 either method. It also addresses the CoRE charter goal to 118 interoperate with DNS-SD. 120 The primary use case for mapping between resource and service 121 discovery is to support heterogeneous HTTP/CoAP environments where, 122 for example, HTTP clients may discover and communicate with CoAP 123 servers that are behind a "cross proxy" [RFC8075]. 125 1.1. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. The term "byte" is used in its now conventional sense as 131 a synonym for "octet". 133 This specification requires readers to be familiar with all the terms 134 and concepts that are discussed in [RFC6690] and [RFC8288]. Readers 135 should also be familiar with the terms and concepts discussed in 136 [RFC7252]. 138 This specification also incorporates the terminology of 139 [I-D.ietf-core-resource-directory]. 141 In particular, the following terms are used frequently: 143 Endpoint: a web server associated with a specific IP address and 144 port; thus a physical device may host one or more endpoints. 145 Endpoints may also act as clients. 147 Link: Web Linking [RFC8288] defines a Web Link (link) as a typed 148 connection between two resources, comprised of: 150 o a link context, 152 o a link relation type (see Section 2.1 of [RFC8288], 154 o a link target, and 156 o optionally, target attributes (see Section 2.2 of [RFC8288]). 158 A link can be viewed as a statement of the form "link context has a 159 link relation type resource at link target, which (optionally) has 160 target attributes", where link target and context are typically 161 Universal Resource Identifiers (URIs) [RFC3986]. For example, 162 "https://www.example.com/" has a "canonical" resource at 163 "https://example.com", which has a "type" of "text/html". 165 1.2. CoRE Resource Discovery 167 The main function of Resource Discovery is to return links to the 168 resources hosted by a server, complemented by attributes about those 169 resources and additional link relations. In CoRE this collection of 170 links and attributes is itself a resource (in contrast to HTTP, where 171 headers delivered with a specific resource describe its attributes). 173 Resource Discovery can be performed either unicast or multicast. 174 When a server's IP address is already known, either a priori or 175 resolved via the Domain Name System (DNS) [RFC1034][RFC1035], unicast 176 discovery is performed in order to locate the entry point to the 177 resource of interest. This is performed using a GET to "/.well- 178 known/core" on the server, which returns a payload in the CoRE Link 179 Format [RFC6690]. A client would then match the appropriate Resource 180 Type, Interface Description, and possible media type [RFC2045] for 181 its application. These attributes may also be included in the query 182 string in order to filter the number of links returned in a response. 184 Multicast Resource Discovery is useful when a client needs to locate 185 a resource within a limited scope, and that scope supports IP 186 multicast. A GET request to the appropriate multicast address is 187 made for "/.well-known/core". In order to limit the number and size 188 of responses, a query string is recommended with the known 189 attributes. Typically, a resource would be discovered based on its 190 Resource Type and/or Interface Description, along with possible 191 application-specific attributes. 193 1.3. CoRE Resource Directories 195 In many M2M scenarios, direct discovery of resources is not practical 196 due to sleeping nodes, limited bandwidth, or networks where multicast 197 traffic is inefficient. These problems can be solved by deploying a 198 network element called a Resource Directory (RD), which hosts 199 descriptions of resources that originate on other endpoints and 200 allows indirect lookups to be performed for those resources. 202 The Resource Directory implements a set of REST interfaces for 203 endpoints to register and maintain collections of links, called 204 Resource Directory registrations. [I-D.ietf-core-resource-directory] 205 specifies the web interfaces that an RD supports for endpoints to 206 discover the RD and to register, maintain, lookup and remove resource 207 descriptions; for the RD to validate entries; and for clients to 208 lookup resources from the RD. 210 1.4. DNS-Based Service Discovery 212 DNS-Based Service Discovery (DNS-SD) defines a conventional method of 213 naming and configuring DNS PTR, SRV, and TXT resource records to 214 facilitate discovery of services (such as CoAP servers in a 215 subdomain) using the existing DNS infrastructure. This section gives 216 a brief overview of DNS-SD; for a detailed specification see 217 [RFC6763]. 219 DNS-SD Service Names are limited to 255 bytes and are of the form: 221 Service Name = .. 223 The Service Name identifies a SRV/TXT Resource Record (RR) pair. The 224 SRV RR specifies the hostname and port of an endpoint. The TXT RR 225 provides additional information in the form of key/value pairs. DNS- 226 Based Service Discovery is accomplished by sending a DNS request for 227 PTR records with the name ., which will return a 228 list of zero or more Service Names. 230 The part of the Service Name is identical to the global (DNS 231 subdomain) part of the authority in URIs [RFC3986] that identify the 232 resources on an individual server or group of servers. 234 The part is generally composed of two labels. The 235 first label of the pair is the application protocol name [RFC6335] 236 preceded by an underscore character. For example, an organization 237 such as the Open Connectivity Foundation [OCF] that specifies 238 Resource Types [RFC6335] might register application protocol names 239 beginning with "oic", which all servers that advertise OCF resources 240 would use as part of their ServiceType. The second label indicates 241 the transport protocol binding and is typically "_udp" for CoAP 242 services. 244 The default part of the Service Name SHOULD be set to a 245 default value at the factory and MAY be modified during the 246 commissioning process. It MUST uniquely identify an instance of 247 within a . Taken together, these three 248 elements comprise a unique name for an SRV/TXT record pair within the 249 DNS subdomain. 251 The granularity of a Service Name MAY be that of a host or group, or 252 it might represent a particular resource within a CoAP server. The 253 SRV record contains the host name (AAAA record name) and port of the 254 endpoint, while protocol is part of the Service Name. In the case 255 where a Service Name identifies a particular resource, the path part 256 of the URI must be carried in a corresponding TXT record. 258 A DNS TXT record is in practice limited to a few hundred bytes in 259 length, which is indicated in the resource record header in the DNS 260 response message (See section 6 of [RFC6763]). The data consist of 261 one or more strings comprising a key/value pair. By convention, the 262 first pair is txtver= (to support different versions of a 263 service description). Each string is formatted as a single length 264 byte followed by 0-255 bytes of text. An example string is: 266 ---------------------------------------- 267 | 0x08 | t | x | t | v | e | r | = | 1 | 268 ---------------------------------------- 270 2. New Link-Format Attributes 272 When using the CoRE Link Format to describe resources being 273 discovered by or posted to a resource directory service, additional 274 information about those resources is often useful. This 275 specification defines the following new attributes for use in the 276 CoRE Link Format [RFC6690] to enable the data-driven mappings 277 described in Section 3: 279 link-extension = ( "exp" ) 280 link-extension = ( "ins" "=" (ptoken | quoted-string) ) 281 ; The token or string is max 63 bytes 282 link-extension = ( "st" "=" (ptoken | quoted-string) ) 283 ; The token or string is max 15 bytes 285 2.1. Export attribute "exp" 287 The Export "exp" attribute is used as a flag to indicate that a link 288 description MAY be exported from a resource directory to external 289 directories. 291 The CoRE Link Format is used for many purposes between CoAP 292 endpoints. Some are useful mainly locally; for example checking the 293 observability of a resource before accessing it, determining the size 294 of a resource, or traversing dynamic resource structures. However, 295 other links are very useful to be exported to other directories, for 296 example the entry point resource to a functional service. This 297 attribute MAY be used as a query parameter in the RD Lookup Function 298 Set defined in Section 6 of [I-D.ietf-core-resource-directory]. 300 2.2. Resource Instance attribute "ins=" 302 The Resource Instance "ins=" attribute is an identifier for this 303 resource, which makes it possible to distinguish it from other 304 similar resources in a Resource Directory. This attribute specifies 305 the value to be used for the portion of an exported DNS-SD 306 Service Name (see Section 1.4), and SHOULD be unique across resources 307 with the same Resource Type "rt=" attribute in the domain in which it 308 is used. 310 A Resource Instance SHOULD be a descriptive human readable string 311 like "Ceiling Light, Room 3". This attribute MUST NOT be more than 312 63 bytes in length. The resource identifier attribute MUST NOT 313 appear more than once in a link description. This attribute MAY be 314 used as a query parameter in the RD Lookup Function Set defined in 315 Section 7 of [I-D.ietf-core-resource-directory]. 317 2.3. Service Type attribute "st=" 319 The Service Type instance "st=" attribute specifies the value to be 320 used for the portion of an exported DNS-SD Service Name 321 (see Section 1.4). This attribute MUST NOT be more than 15 bytes in 322 length (see [RFC6335], Section 5.1) and MUST be present in the IANA 323 Service Name registry [st]. 325 3. Mapping CoRE Link Attributes to DNS-SD Record Fields 327 3.1. Mapping Resource Instance attribute "ins=" to 329 The Resource Instance "ins=" attribute maps directly to the 330 part of a DNS-SD Service Name. It is stored directly in 331 the DNS as a single DNS label of canonical precomposed UTF-8 332 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] 333 text. However, if the "ins=" attribute is chosen to match the DNS 334 host name of a service, it SHOULD use the syntax defined in 335 Section 3.5 of [RFC1034] and Section 2.1 of [RFC1123]. 337 The part of the name of a service being offered on the 338 network SHOULD be configurable by the user setting up the service, so 339 that he or she may give it an informative name. However, the device 340 or service SHOULD NOT require the user to configure a name before it 341 can be used. A sensible choice of default name can allow the device 342 or service to be accessed in many cases without any manual 343 configuration at all (see Appendix D of [RFC6763]). 345 DNS labels are limited to 63 bytes in length and the entire Service 346 Name may not exceed 255 bytes. 348 3.2. Mapping Service Type attribute "st=" to 350 The Service Type "st=" attribute maps directly to the 351 part of a DNS-SD Service Name. 353 In practice, the ServiceType should unambiguously identify 354 interoperable devices. It is up to individual SDOs to specify how to 355 represent their registered Resource Type "rt=" values as registered 356 application protocol names according to [RFC6335]. The application 357 name is then used as the value of the resource "st=" attribute. 359 The resulting application protocol name MUST be composed of at least 360 a single Net-Unicode text string, without underscore '_' or period 361 '.' and limited to 15 bytes in length (see Section 5.1 of [RFC6335]). 362 This string is mapped to the DNS-SD by prepending an 363 underscore and appending a period followed by the "_udp" label. For 364 example, rt="oic.d.light" might correspond to the registered 365 application protocol name st="oic-d-light" and would be mapped into 366 Service Type "_oic-d-light._udp". 368 The resulting string is used to form labels for DNS-SD records which 369 are stored directly in the DNS. 371 3.3. Mapping 373 TBD: A method must be specified to determine which DNS zone the CoAP 374 service description should be exported to. See, for example, 375 Section 11 in [RFC6763] and Section 2 in 376 [I-D.sctl-service-registration]. 378 3.4. TXT Record key=value strings 380 DNS-SD key/value pairs may be derived from CoRE Link Format 381 information and exported as key=value strings in a DNS-SD TXT record 382 (See Section 6.3 of [RFC6763]). 384 The resource is exported as key/value pair "path=". 386 The Interface Description "if=" attribute is exported as key/value 387 pair "if=". 389 The DNS TXT record can be further populated by importing any other 390 resource description attributes as they share the same key=value 391 format specified in Section 6 of [RFC6763]. 393 3.5. Exporting resource links into DNS-SD 395 Assuming the ability to query a Resource Directory or multicast a GET 396 (?exp) over the local link, CoAP resource discovery may be used to 397 populate the DNS-SD database in an automated fashion. CoAP resource 398 descriptions (links) can be exported to DNS-SD for exposure to 399 service discovery by using the Resource Instance attribute as the 400 basis for a unique Service Name, composed with the Service Type 401 attribute as the , and registered in the appropriate 402 . The agent responsible for exporting records to the DNS 403 zone file SHOULD be authenticated to the DNS server. The following 404 example, using the example lookup location /rd-lookup, shows an agent 405 discovering a resource to be exported: 407 Req: GET /rd-lookup/res?exp 409 Res: 2.05 Content 410 ; 411 exp;st=oic-d-light;rt="oic.d.light";ins="Spot"; 412 d="sector";ep="node1" 414 The agent subsequently registers the following DNS-SD RRs, assuming a 415 derived DNS zone name "office.example.com": 417 _oic-d-light._udp.office.example.com IN PTR 418 Spot._oic-d-light._udp.office.example.com 419 Spot._oic-d-light._udp.office.example.com IN TXT 420 txtver=1;path=/light/1;rt=oic.d.light;d=sector 421 Spot._oic-d-light._udp.office.example.com IN SRV 422 0 0 5683 node1.office.example.com. 423 node1.office.example.com. IN AAAA FDFD::1234 425 4. Exporting Resource Directory Service to DNS 427 In some cases it is required that one (or more) Resource Directories 428 (RD) in a given DNS domain can be discoverable from DNS. The /.well- 429 known/core resource of the RD should reflect this by specifying the 430 "ins", "exp", and the "st" attributes in the the link of the RD 431 service. This document specifies in Section 5 two servicetypes: _rd- 432 lookup-res._udp and _rd-lookup-ep._udp for resource types rt = 433 core.rd-lookup-res and rt = core.rd-lookup-ep respectively. The 434 default coap and coaps ports are respectively: 5683 and 5684. 436 The value of the instance MAY be specified by the manager of the 437 resource directories. In case of an unmanaged RD (for example in a 438 home network) it is recommended that the ins parameter takes a value 439 provided by an Authorization Server during the acceptance of the RD 440 to the network (see for example section 7 of 441 [I-D.ietf-core-resource-directory]). 443 With the assumption that the "ins" value is attributed by 444 Authorization Server, and [FDFD::1234] is IP address of RD, Example 445 links for RD are: 447 Req: GET coap://[FDFD::1234]/.well-known/core?exp 449 Res: 2.05 Content 450 ; 451 exp;st=rd-lookup-res;rt="core.rd-lookup-res"; 452 ins="505567", 453 ; 454 exp;st=rd-lookup-ep;rt="core.rd-lookup-ep"; 455 ins="505572" 457 The link atributes can be exported to RR by the mapping process 458 described in Section 3. 460 5. IANA considerations 462 Two registries are affected by this document: (1) "RD Parameters" 463 registry under "Core Parameters" registry, and (2) Service Name and 464 Transport Protocol Port Number Registry 466 5.1. RD Parameters Registry 468 This specification defines new parameters for the registry "RD 469 Parameters" provided under "CoRE Parameters" (TBD). 471 +----------------+-------+---------------+-----+--------------------+ 472 | Full name | Short | Validity | Use | Description | 473 +----------------+-------+---------------+-----+--------------------+ 474 | ServiceType | st | | RLA | Name of the | 475 | | | | |Service Type, | 476 | | | | | max 63 bytes | 477 | Resource | ins | | RLA | Instance identifier| 478 | Instance | | | | of the resource | 479 | | | | | | 480 | Export | exp | | RLA | flag to indicate | 481 | | | | | exportation | 482 +----------------+-------+---------------+-----+--------------------+ 484 5.2. Service Name and Transport Protocol Port Number Registry 486 This specification defines new parameters for the Service Name and 487 Transport Protocol Port Number Registry: 489 * _rd-lookup-res._udp at ports 5683 and 5684 490 * _rd-lookup-ep._udp at ports 5683 and 5684 492 6. Security considerations 494 Malicious nodes can export fake link attributes to DNS. It is 495 recommended that the RD can be authenticated, and is authorized to 496 both join the network and export its link attributes. Authentication 497 is specified in [I-D.ietf-ace-oauth-authz]. 499 7. Contributors 501 Keryy lynn was the initiator of, and major contributor to this 502 document. This document was split out from 503 [I-D.ietf-core-resource-directory]. Zach Shelby was a co-author of 504 the original version of this draft. 506 8. Acknowledgments 508 The authors wish to thank Stuart Cheshire, Ted Lemon, and David 509 Thaler for their thorough reviews and clarifying suggestions. 511 9. References 513 9.1. Normative References 515 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 516 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 517 . 519 [RFC1035] Mockapetris, P., "Domain names - implementation and 520 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 521 November 1987, . 523 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 524 Application and Support", STD 3, RFC 1123, 525 DOI 10.17487/RFC1123, October 1989, 526 . 528 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 529 Extensions (MIME) Part One: Format of Internet Message 530 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 531 . 533 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 534 Requirement Levels", BCP 14, RFC 2119, 535 DOI 10.17487/RFC2119, March 1997, 536 . 538 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 539 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 540 2003, . 542 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 543 Resource Identifier (URI): Generic Syntax", STD 66, 544 RFC 3986, DOI 10.17487/RFC3986, January 2005, 545 . 547 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, 548 "Transmission of IPv6 Packets over IEEE 802.15.4 549 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, 550 . 552 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 553 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 554 . 556 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 557 Cheshire, "Internet Assigned Numbers Authority (IANA) 558 Procedures for the Management of the Service Name and 559 Transport Protocol Port Number Registry", BCP 165, 560 RFC 6335, DOI 10.17487/RFC6335, August 2011, 561 . 563 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 564 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 565 . 567 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 568 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 569 . 571 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 572 Application Protocol (CoAP)", RFC 7252, 573 DOI 10.17487/RFC7252, June 2014, 574 . 576 [RFC8075] Castellani, A., Loreto, S., Rahman, A., Fossati, T., and 577 E. Dijk, "Guidelines for Mapping Implementations: HTTP to 578 the Constrained Application Protocol (CoAP)", RFC 8075, 579 DOI 10.17487/RFC8075, February 2017, 580 . 582 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 583 DOI 10.17487/RFC8288, October 2017, 584 . 586 9.2. Informative References 588 [I-D.handrews-json-schema-hyperschema] 589 Andrews, H. and A. Wright, "JSON Hyper-Schema: A 590 Vocabulary for Hypermedia Annotation of JSON", draft- 591 handrews-json-schema-hyperschema-01 (work in progress), 592 January 2018. 594 [I-D.ietf-ace-oauth-authz] 595 Seitz, L., Selander, G., Wahlstroem, E., Erdtman, S., and 596 H. Tschofenig, "Authentication and Authorization for 597 Constrained Environments (ACE) using the OAuth 2.0 598 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 599 (work in progress), March 2019. 601 [I-D.ietf-core-resource-directory] 602 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 603 Amsuess, "CoRE Resource Directory", draft-ietf-core- 604 resource-directory-22 (work in progress), July 2019. 606 [I-D.sctl-service-registration] 607 Cheshire, S. and T. Lemon, "Service Registration Protocol 608 for DNS-Based Service Discovery", draft-sctl-service- 609 registration-02 (work in progress), July 2018. 611 [OCF] Foundation, O., "OCF Specification 2.0", 2018, 612 . 614 [REST] Fielding, R., "Architectural Styles and the Design of 615 Network-based Software Architectures", 2000, 616 . 619 [rt] IANA, ., "Resource Type (rt=) Link Target Attribute 620 Values", 2012, . 624 [st] IANA, ., "Service Name and Transport Protocol Port Number 625 Registry", 2018, . 629 Authors' Addresses 631 Peter van der Stok 632 Consultant 634 Phone: +31 492474673 (Netherlands), +33 966015248 (France) 635 Email: consultancy@vanderstok.org 636 URI: www.vanderstok.org 638 Michael Koster 639 SmartThings 640 665 Clyde Avenue 641 Mountain View, CA 94043 642 USA 644 Phone: +1 707-502-5136 645 Email: Michael.Koster@smartthings.com 647 Christian Amsuess 648 Energy Harvesting Solutions 649 Hollandstr. 12/4 650 1020 651 Austria 653 Phone: +43 664-9790639 654 Email: c.amsuess@energyharvesting.at