idnits 2.17.1 draft-ietf-core-rd-dns-sd-03.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 (October 22, 2018) is 2005 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 (-28) exists of draft-ietf-core-resource-directory-15 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE K. Lynn 3 Internet-Draft Oracle + Dyn 4 Intended status: Standards Track P. van der Stok 5 Expires: April 25, 2019 Consultant 6 M. Koster 7 SmartThings 8 C. Amsuess 9 Energy Harvesting Solutions 10 October 22, 2018 12 CoRE Resource Directory: DNS-SD mapping 13 draft-ietf-core-rd-dns-sd-03 15 Abstract 17 Resource and service discovery are complimentary. Resource discovery 18 provides fine-grained detail about the content of a server, while 19 service discovery can provide a scalable method to locate servers in 20 large networks. This document defines a method for mapping between 21 CoRE Link Format attributes and DNS-Based Service Discovery fields to 22 facilitate the use of either method to locate RESTful service 23 interfaces (APIs) in heterogeneous HTTP/CoAP environments. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on April 25, 2019. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.2. CoRE Resource Discovery . . . . . . . . . . . . . . . . . 3 62 1.3. CoRE Resource Directories . . . . . . . . . . . . . . . . 4 63 1.4. DNS-Based Service Discovery . . . . . . . . . . . . . . . 5 64 2. Mapping from web resources DNS services . . . . . . . . . . . 6 65 2.1. Domain mapping . . . . . . . . . . . . . . . . . . . . . 6 66 2.2. ServiceType mapping . . . . . . . . . . . . . . . . . . . 6 67 2.3. Instance mapping . . . . . . . . . . . . . . . . . . . . 7 68 3. New Link-Format Attributes . . . . . . . . . . . . . . . . . 7 69 3.1. Export attribute "exp" . . . . . . . . . . . . . . . . . 7 70 3.2. Resource Instance attribute "ins" . . . . . . . . . . . . 8 71 4. Mapping CoRE Link Attributes to DNS-SD Record Fields . . . . 8 72 4.1. Mapping Resource Instance attribute "ins" to . 8 73 4.2. Mapping Resource Type attribute "rt" to . . 9 74 4.3. TXT Record key=value strings . . . . . . . . . . . . . . 9 75 4.4. Exporting resource links into DNS-SD . . . . . . . . . . 10 76 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Mapping Resource Type into ServiceType . . . . . . . . . 10 78 6. Security considerations . . . . . . . . . . . . . . . . . . . 10 79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 80 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 81 7.2. Informative References . . . . . . . . . . . . . . . . . 12 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 The Constrained RESTful Environments (CoRE) working group aims at 88 realizing the REST architecture in a suitable form for the most 89 constrained devices (e.g. 8-bit microcontrollers with limited RAM and 90 ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- 91 machine (M2M) applications such as smart energy and building 92 automation. The main deliverable of CoRE is the Constrained 93 Application Protocol (CoAP) specification [RFC7252]. 95 Automated discovery of resources hosted by a constrained server is 96 critical in M2M applications where human intervention is minimal and 97 static interfaces result in brittleness. CoRE Resource Discovery is 98 intended to support fine-grained discovery of hosted resources, their 99 attributes, and possibly other resource relations [RFC6690]. 101 In contrast to resource discovery, service discovery generally refers 102 to a coarser-grained resolution of an endpoint's IP address, port 103 number, and protocol. This definition may be extended to include 104 multi-function devices, where the result of the discovery process may 105 include a path to a resource representing a RESTful service interface 106 and possibly a reference to a description of the interface such as a 107 JSON Hyper-Schema document [I-D.handrews-json-schema-hyperschema] per 108 function. 110 Resource and service discovery are complimentary in the case of large 111 networks, where the latter can facilitate scaling. This document 112 defines a mapping between CoRE Link Format attributes and DNS-Based 113 Service Discovery (DNS-SD) [RFC6763] fields that permits discovery of 114 CoAP services by either method. It also addresses the CoRE charter 115 goal to interoperate with DNS-SD. 117 The actual publishing of DNS services on the basis of the contents of 118 the Resource Directory is the subject of 119 [I-D.sctl-service-registration]. 121 1.1. Terminology 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 125 "OPTIONAL" in this document are to be interpreted as described in 126 [RFC2119]. The term "byte" is used in its now conventional sense as 127 a synonym for "octet". 129 This specification requires readers to be familiar with all the terms 130 and concepts that are discussed in [RFC6690] and [RFC8288]. Readers 131 should also be familiar with the terms and concepts discussed in 132 [RFC7252]. To describe the REST interfaces defined in this 133 specification, the URI Template format is used [RFC6570]. 135 This specification also incorporates the terminology of 136 [I-D.ietf-core-resource-directory]. 138 1.2. CoRE Resource Discovery 140 [RFC8288] defines a Web Link (link) as a typed connection between two 141 resources, comprised of: 143 o a link context, 144 o a link relation type (see Section 2.1 of [RFC8288], 146 o a link target, and 148 o optionally, target attributes (see Section 2.2 of [RFC8288]). 150 A link can be viewed as a statement of the form "link context has a 151 link relation type resource at link target, which (optionally) has 152 target attributes", where link target (and context) is typically a 153 Universal Resource Identifier (URI) [RFC3986]. 155 For example, "https://www.example.com/" has a "canonical" resource at 156 "https://example.com", which has a "type" of "text/html". 158 The main function of Resource Discovery is to return links to the 159 resources hosted by a server, complemented by attributes about those 160 resources and additional link relations. In CoRE this collection of 161 links and attributes is itself a resource (as opposed to HTTP headers 162 delivered with a specific resource). 164 [RFC6690] specifies a link format for use in CoRE Resource Discovery 165 by extending the HTTP Link Header Format [RFC8288] to describe these 166 link descriptions. The CoRE Link Format is carried as a payload and 167 is serialized according to one of several Internet media types. CoRE 168 Resource Discovery is accomplished by sending a GET request to the 169 well-known URI "/.well- known/core", which is defined as a default 170 entry-point for requesting the collection of links to resources 171 hosted by a server. 173 Resource Discovery can be performed either via 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 a URI for the resource of 177 interest. This is performed using a GET to /.well-known/core on the 178 server, which returns the links. A client would then match the 179 appropriate Resource Type, Interface Description, and possible 180 Content-Type [RFC2045] for its application. These attributes may 181 also be included in the query string in order to filter the number of 182 links returned in a response. 184 1.3. CoRE Resource Directories 186 In many M2M scenarios, direct discovery of resources is not practical 187 due to sleeping nodes, limited bandwidth, or networks where multicast 188 traffic is inefficient. These problems can be solved by deploying a 189 network element called a Resource Directory (RD), which hosts 190 descriptions of resources held on other servers (referred to as "end- 191 points") and allows lookups to be performed for those resources. An 192 endpoint is a web server associated with a specific IP address and 193 port; thus a physical device may host one or more endpoints. End- 194 points may also act as clients. 196 The Resource Directory implements a set of REST interfaces for end- 197 points to register and maintain collections of links, called resource 198 directory registrations. [I-D.ietf-core-resource-directory] 199 specifies the web interfaces that an RD supports for endpoints to 200 discover the RD and to register, maintain, lookup and remove resource 201 descriptions; for the RD to validate entries; and for clients to 202 lookup resources from the RD. 204 1.4. DNS-Based Service Discovery 206 DNS-Based Service Discovery (DNS-SD) defines a conventional method of 207 naming and configuring DNS PTR, SRV, and TXT resource records to 208 facilitate discovery of services (such as CoAP servers in a 209 subdomain) using the existing DNS infrastructure. This section gives 210 a brief overview of DNS-SD; for a detailed specification see 211 [RFC6763]. 213 DNS-SD Service Names are limited to 255 bytes and are of the form: 215 Service Name = .. 217 The Service Name identifies a SRV/TXT resource record (RR) pair. The 218 SRV RR specifies the host and port of an endpoint. The TXT RR 219 provides additional information in the form of key/value pairs. DNS- 220 Based Service Discovery is accomplished by sending a DNS request for 221 PTR records with the name ., which will return a 222 list of zero or more Service Names. 224 The part of the Service Name is identical to the global (DNS 225 subdomain) part of the authority in URIs that identify the resources 226 on an individual server or group of servers. 228 The part is composed of at least two labels. The first 229 label of the pair is the application protocol name [RFC6335] preceded 230 by an underscore character. For example, an organization such as the 231 Open Connectivity Foundation [OCF] that specifies resources might 232 register the application protocol name "_oic", which all servers that 233 advertise OCF resources would use as part of their ServiceType. The 234 second label indicates the transport and is typically "_udp" for CoAP 235 services. In cases where narrowing the scope of the search may be 236 useful, these labels may be optionally preceded by a subtype name 237 followed by the "_sub" label. An example of this more specific 238 is "light._sub._oic._udp". 240 The default part of the Service Name SHOULD be set to a 241 default value at the factory and MAY be modified during the 242 commissioning process. It MUST uniquely identify an instance of 243 within a . Taken together, these three 244 elements comprise a unique name for an SRV/TXT record pair within the 245 DNS subdomain. 247 The granularity of a Service Name MAY be that of a host or group, or 248 it might represent a particular resource within a CoAP server. The 249 SRV record contains the host name (AAAA record name) and port of the 250 endpoint while protocol is part of the Service Name. In the case 251 where a Service Name identifies a particular resource, the path part 252 of the URI must be carried in a corresponding TXT record. 254 A DNS TXT record is in practice limited to a few hundred bytes in 255 length, which is indicated in the resource record header in the DNS 256 response message [RFC6763]. The data consists of one or more strings 257 comprising a key/value pair. By convention, the first pair is 258 txtver= (to support different versions of a service 259 description). An example string is: 261 ---------------------------------------- 262 | 0x08 | t | x | t | v | e | r | = | 1 | 263 ---------------------------------------- 265 2. Mapping from web resources DNS services 267 These sections describe how each of the three parts of the Service 268 Name can be mapped to link attributes. 270 2.1. Domain mapping 272 TBD: A method must be specified to determine in which DNS zone the 273 CoAP service should be registered. See, for example, Section 11 in 274 [RFC6763] and Section 2 in [I-D.sctl-service-registration] 276 2.2. ServiceType mapping 278 ServiceTypes are registered by IANA [st]. They identify services 279 that can be specified by IETF or any other Standards Development 280 Organization (SDO). The IANA resource type registry [rt] is based on 281 the resource type (rt= attribute) [RFC6690] which identifies endpoint 282 functionality specified by IETF or any other SDO. 284 It is expected that an endpoint providing a given ServiceType 285 represents a collection of resources each with its own Resource Type. 286 The Resource Type of the collection MUST be mapped directly to the 287 ServiceType. A registry is required to specify the mapping between 288 Resource Types and ServiceTypes. 290 2.3. Instance mapping 292 The Instance name may be freely chosen by the manufacturer and 293 inserted in the device. During installation the pre-configured 294 Instance name can be pre- or post-fixed with a string to make the 295 (Instance, ServiceType) pair unique within the domain. For manual 296 discovery it is useful when the Instance name is a human readable 297 string containing the manufacturer name or the device type. 299 IoT devices are not necessarily equipped with an Instance name for 300 DNS-SD. To make the (Instance, ServiceType) pair unique, it is 301 sufficient to use another unique identifier stored in the device such 302 as the Public key or UUID of the device. When a human readable name 303 is required, the interface description (if= attribute) [RFC6690] may 304 provide for example, a URN that can be made unique by pre- or post- 305 fixing it with a string as is currently done for the Instance name 306 devices conforming to DNS-SD specification. 308 When the device selects the Instance name, the device, registering 309 with the RD, MUST provide an Instance name in its link. When a third 310 party device, the Commissioning Tool (CT) 311 [I-D.ietf-core-resource-directory], selects the Instance name, it 312 specifies the Instance name when registering the device with the 313 Resource Directory. 315 3. New Link-Format Attributes 317 When using the CoRE Link Format to describe resources being 318 discovered by or posted to a resource directory service, additional 319 information about those resources is useful. This specification 320 defines the following new attributes for use in the CoRE Link Format 321 [RFC6690]: 323 link-extension = ( "exp" ) 324 link-extension = ( "ins" "=" (ptoken | quoted-string) ) 325 ; The token or string is max 63 bytes 327 3.1. Export attribute "exp" 329 The Export "exp" attribute is used as a flag to indicate that a link 330 description MAY be exported from a resource directory to external 331 directories. 333 The CoRE Link Format is used for many purposes between CoAP 334 endpoints. Some are useful mainly locally; for example checking the 335 observability of a resource before accessing it, determining the size 336 of a resource, or traversing dynamic resource structures. However, 337 other links are very useful to be exported to other directories, for 338 example the entry point resource to a functional service. This 339 attribute MAY be used as a query parameter in the RD Lookup Function 340 Set defined in Section 7 of [I-D.ietf-core-resource-directory]. 342 3.2. Resource Instance attribute "ins" 344 The Resource Instance "ins" attribute is an identifier for this 345 resource, which makes it possible to distinguish it from other 346 similar resources. This attribute is equivalent in use to the 347 portion of a DNS-SD record (see Section 1.4), and SHOULD 348 be unique across resources with the same Resource Type attribute in 349 the domain in which it is used. A Resource Instance SHOULD be a 350 descriptive string like "Ceiling Light, Room 3", but MAY be a short 351 ID like "AF39", a unique UUID, or fingerprint of a public key. This 352 attribute is used by a Resource Directory to distinguish between 353 multiple instances of the same resource type within the directory. 355 This attribute MUST NOT be more than 63 bytes in length. The 356 resource identifier attribute MUST NOT appear more than once in a 357 link description. This attribute MAY be used as a query parameter in 358 the RD Lookup Function Set defined in Section 7 of 359 [I-D.ietf-core-resource-directory]. 361 4. Mapping CoRE Link Attributes to DNS-SD Record Fields 363 4.1. Mapping Resource Instance attribute "ins" to 365 The Resource Instance "ins" attribute maps to the part of 366 a DNS-SD Service Name. It is stored directly in the DNS as a single 367 DNS label of canonical precomposed UTF-8 [RFC3629] "Net-Unicode" 368 (Unicode Normalization Form C) [RFC5198] text. However, if the "ins" 369 attribute is chosen to match the DNS host name of a service, it 370 SHOULD use the syntax defined in Section 3.5 of [RFC1034] and 371 Section 2.1 of [RFC1123]. 373 The part of the name of a service being offered on the 374 network SHOULD be configurable by the user setting up the service, so 375 that he or she may give it an informative name. However, the device 376 or service SHOULD NOT require the user to configure a name before it 377 can be used. A sensible choice of default name can allow the device 378 or service to be accessed in many cases without any manual 379 configuration at all (see Appendix D of [RFC6763]). 381 DNS labels are limited to 63 bytes in length and the entire Service 382 Name may not exceed 255 bytes. 384 4.2. Mapping Resource Type attribute "rt" to 386 The part of a DNS-SD Service Name is derived from the 387 "rt" attribute and SHOULD conform to the reg-rel-type production of 388 the Link Format defined in Section 2 of [RFC6690]. 390 In practice, the ServiceType should unambiguously identify inter- 391 operable devices. It is up to individual SDOs to specify how to map 392 between their registered Resource Type (rt=) values and ServiceType 393 values. Two approaches are possible; either a hierachical approach 394 as in Section 1.4 above, or a flat identifier. Both approaches are 395 shown below for illustration, but in practice only ONE would be 396 specified. 398 In either case, the resulting application protocol name MUST be 399 composed of at least a single Net-Unicode text string, without 400 underscore '_' or or period '.' and limited to 15 bytes in length 401 (see Section 5.1 of [RFC6335]). This string is mapped to the DNS-SD 402 by prepending an underscore and appending a period 403 followed by the "_udp" label. For example, rt="oic.d.light" might be 404 mapped into "_oic-d-light._udp". 406 The application protocol name may be optionally followed by a period 407 and a service subtype name consisting of a Net-Unicode text string, 408 without underscore or period and limited to 63 bytes. This string is 409 mapped to the DNS-SD by appending a period followed by 410 the "_sub" label and then appending a period followed by the service 411 type label pair derived as in the previous paragraph. For example, 412 rt="oic.d.light" might be mapped into "light._sub._oic._udp". 414 The resulting string is used to form labels for DNS-SD records which 415 are stored directly in the DNS. 417 4.3. TXT Record key=value strings 419 A number of [RFC6763] key/value pairs are derived from link-format 420 information, to be exported in the DNS-SD as key=value strings in a 421 TXT record (See Section 6.3 of [RFC6763]). 423 The resource is exported as key/value pair "path=". 425 The Interface Description "if" attribute is exported as key/value 426 pair "if=". 428 The DNS TXT record can be further populated by importing any other 429 resource description attributes as they share the same key=value 430 format specified in Section 6 of [RFC6763]. 432 4.4. Exporting resource links into DNS-SD 434 Assuming the ability to query a Resource Directory or multicast a GET 435 (?exp) over the local link, CoAP resource discovery may be used to 436 populate the DNS-SD database in an automated fashion. CoAP resource 437 descriptions (links) can be exported to DNS-SD for exposure to 438 service discovery by using the Resource Instance attribute as the 439 basis for a unique Service Name, composed with the Resource Type as 440 the , and registered in the correct . The agent 441 responsible for exporting records to the DNS zone file SHOULD be 442 authenticated to the DNS server. The following example, using the 443 example lookup location /rd-lookup, shows an agent discovering a 444 resource to be exported: 446 Req: GET /rd-lookup/res?exp 448 Res: 2.05 Content 449 ; 450 exp;rt="oic.d.light";ins="Spot"; 451 d="office";ep="node1" 453 The agent subsequently registers the following DNS-SD RRs, assuming a 454 zone name "example.com" prefixed with "office": 456 _oic._udp.office.example.com IN PTR 457 Spot._oic._udp.office.example.com 458 light._sub._oic._udp.example.com IN PTR 459 Spot._oic._udp.office.example.com 460 Spot._oic._udp.office.example.com IN TXT 461 txtver=1;path=/light/1 462 Spot._oic._udp.office.example.com IN SRV 0 0 5683 463 node1.office.example.com. 464 node1.office.example.com. IN AAAA FDFD::1234 466 In the above figure the Service Name is chosen as 467 Spot._oic._udp.office.example.com without the light._sub service 468 prefix. An alternative Service Name would be: 469 Spot.light._sub._oic._udp.office.example.com. 471 5. IANA considerations 473 5.1. Mapping Resource Type into ServiceType 475 TBD 477 6. Security considerations 479 TBD 481 7. References 483 7.1. Normative References 485 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 486 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 487 . 489 [RFC1035] Mockapetris, P., "Domain names - implementation and 490 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 491 November 1987, . 493 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 494 Application and Support", STD 3, RFC 1123, 495 DOI 10.17487/RFC1123, October 1989, 496 . 498 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 499 Extensions (MIME) Part One: Format of Internet Message 500 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 501 . 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, 505 DOI 10.17487/RFC2119, March 1997, 506 . 508 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 509 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 510 2003, . 512 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 513 Resource Identifier (URI): Generic Syntax", STD 66, 514 RFC 3986, DOI 10.17487/RFC3986, January 2005, 515 . 517 [RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network 518 Interchange", RFC 5198, DOI 10.17487/RFC5198, March 2008, 519 . 521 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 522 Cheshire, "Internet Assigned Numbers Authority (IANA) 523 Procedures for the Management of the Service Name and 524 Transport Protocol Port Number Registry", BCP 165, 525 RFC 6335, DOI 10.17487/RFC6335, August 2011, 526 . 528 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 529 and D. Orchard, "URI Template", RFC 6570, 530 DOI 10.17487/RFC6570, March 2012, 531 . 533 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 534 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 535 . 537 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 538 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 539 . 541 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 542 Application Protocol (CoAP)", RFC 7252, 543 DOI 10.17487/RFC7252, June 2014, 544 . 546 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 547 DOI 10.17487/RFC8288, October 2017, 548 . 550 7.2. Informative References 552 [I-D.handrews-json-schema-hyperschema] 553 Andrews, H. and A. Wright, "JSON Hyper-Schema: A 554 Vocabulary for Hypermedia Annotation of JSON", draft- 555 handrews-json-schema-hyperschema-01 (work in progress), 556 January 2018. 558 [I-D.ietf-core-resource-directory] 559 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 560 Amsuess, "CoRE Resource Directory", draft-ietf-core- 561 resource-directory-15 (work in progress), October 2018. 563 [I-D.sctl-service-registration] 564 Cheshire, S. and T. Lemon, "Service Registration Protocol 565 for DNS-Based Service Discovery", draft-sctl-service- 566 registration-02 (work in progress), July 2018. 568 [OCF] Open Connectivity Foundation, "OCF Specification 2.0", 569 2018, . 572 [rt] IANA, "Resource Type (rt=) Link Target Attribute 573 Values", 2012, . 577 [st] IANA, "Service Name and Transport Protocol Port Number 578 Registry", 2018, . 582 Appendix A. Acknowledgments 584 This document was split out from [I-D.ietf-core-resource-directory]. 585 Zach Shelby was a co-author of the original version of this draft. 587 Authors' Addresses 589 Kerry Lynn 590 Oracle + Dyn 591 150 Dow Street, Tower Two 592 Manchester, NH 03101 593 USA 595 Phone: +1 978-460-4253 596 Email: kerlyn@ieee.org 598 Peter van der Stok 599 Consultant 601 Phone: +31 492474673 (Netherlands), +33 966015248 (France) 602 Email: consultancy@vanderstok.org 603 URI: www.vanderstok.org 605 Michael Koster 606 SmartThings 607 665 Clyde Avenue 608 Mountain View, CA 94043 609 USA 611 Phone: +1 707-502-5136 612 Email: Michael.Koster@smartthings.com 614 Christian Amsuess 615 Energy Harvesting Solutions 616 Hollandstr. 12/4 617 1020 618 Austria 620 Phone: +43 664-9790639 621 Email: c.amsuess@energyharvesting.at