idnits 2.17.1 draft-shelby-core-resource-directory-00.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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 216: '... using HTTP [RFC2616]. An RD implementing this specification MUST...' RFC 2119 keyword, line 218: '...this section and MAY support the valid...' RFC 2119 keyword, line 220: '...is specification SHOULD support Etag v...' RFC 2119 keyword, line 246: '...is specification MUST support query fi...' RFC 2119 keyword, line 261: '...urce Type (rt): MUST contain the valu...' (18 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 27, 2011) is 4687 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 (-14) exists of draft-ietf-core-link-format-06 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) == Outdated reference: A later version (-18) exists of draft-ietf-core-coap-06 == Outdated reference: A later version (-04) exists of draft-shelby-core-coap-req-01 == Outdated reference: A later version (-05) exists of draft-vanderstok-core-bc-03 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CoRE Z. Shelby 3 Internet-Draft Sensinode 4 Intended status: Standards Track S. Krco 5 Expires: December 29, 2011 Ericsson 6 June 27, 2011 8 CoRE Resource Directory 9 draft-shelby-core-resource-directory-00 11 Abstract 13 In many M2M scenarios, direct discovery of resources is not practical 14 due to sleeping nodes, disperse networks, or networks where multicast 15 traffic is inefficient. These problems can be solved by employing an 16 entity called a Resource Directory (RD), which hosts descriptions of 17 resources held on other servers, allowing lookups to be performed for 18 those resources. This document specifies the web interfaces that a 19 Resource Directory supports in order for web servers to discover the 20 RD and to registrer, maintain, lookup and remove resources 21 descriptions. Furthermore, new link attributes useful in conjunction 22 with an RD are defined. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on December 29, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Architecture and Use Cases . . . . . . . . . . . . . . . . . . 3 60 2.1. Use Case: Cellular M2M . . . . . . . . . . . . . . . . . . 4 61 2.2. Use Case: Home and Building Automation . . . . . . . . . . 5 62 3. Resource Directory Interfaces . . . . . . . . . . . . . . . . 5 63 3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.2. Registration . . . . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Update . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 3.4. Validation . . . . . . . . . . . . . . . . . . . . . . . . 10 67 3.5. Removal . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.6. Lookup . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 4. New Link-Format Attributes . . . . . . . . . . . . . . . . . . 13 70 4.1. Resource Instance 'ins' attribute . . . . . . . . . . . . 14 71 4.2. Export 'exp' attribute . . . . . . . . . . . . . . . . . . 14 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 75 8. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 78 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 81 1. Introduction 83 The Constrained RESTful Environments (CoRE) working group aims at 84 realizing the REST architecture in a suitable form for the most 85 constrained nodes (e.g. 8-bit microcontrollers with limited RAM and 86 ROM) and networks (e.g. 6LoWPAN). CoRE is aimed at machine-to- 87 machine (M2M) applications such as smart energy and building 88 automation [I-D.shelby-core-coap-req]. 90 The discovery of resources offered by a constrained server is very 91 important in machine-to-machine applications where there are no 92 humans in the loop and static interfaces result in fragility. The 93 discovery of resources provided by an HTTP Web Server is typically 94 called Web Linking [RFC5988]. The use of Web Linking for the 95 description and discovery of resources hosted by constrained web 96 servers is specified by the CoRE Link Format 97 [I-D.ietf-core-link-format]. This specification however only 98 describes how to discover resources from the web server that hosts 99 them by requesting /.well-known/core. In many M2M scenarios, direct 100 discovery of resources is not practical due to sleeping nodes, 101 disperse networks, or networks where multicast traffic is 102 inefficient. These problems can be solved by employing an entity 103 called a Resource Directory (RD), which hosts descriptions of 104 resources held on other servers, allowing lookups to be performed for 105 those resources. 107 This document specifies the web interfaces that a Resource Directory 108 supports in order for web servers to discover the RD and to 109 registrer, maintain, lookup and remove resources descriptions. 110 Furthermore, new link attributes useful in conjunction with a 111 Resource Directory are defined. Although the examples in this 112 document show the use of these interfaces with CoAP 113 [I-D.ietf-core-coap], they may be applied in an equivalent manner to 114 HTTP [RFC2616]. 116 2. Architecture and Use Cases 118 The resource directory architecture is shown in Figure 1. A Resource 119 Directory (RD) is used as a repository for Web Links [RFC5988] about 120 resources hosted on other web servers, which are called end-points 121 (EP). An end-point is a web server associated with a port, thus a 122 physical node may host one or more end-points. The RD implements a 123 set of REST interfaces for end-points to register and maintain sets 124 of Web Links (called resource directory entries), for the RD to 125 validate entries, and for clients to lookup resources from the RD. 126 End-points themselves can also act as clients. 128 End-points are assumed to proactively register and maintain resource 129 directory entries on the RD, which are soft state and need to be 130 periodially refreshed. An EP is provided with interfaces to 131 register, update and remove a resource directory entry. Furthermore, 132 a mechanism to discover a RD using the CoRE Link Format is defined. 133 It is also possible for an RD to proactively discover Web Links from 134 EPs and add them as resource directory entries, or to validate 135 existing resource directory entries. A lookup interface for 136 discovering any of the Web Links held in the RD is provided using the 137 CoRE Link Format. 139 Registration Lookup 140 +----+ | | 141 | EP |---- | | 142 +----+ ---- | | 143 --|- +------+ | 144 +----+ | ----| | | +--------+ 145 | EP | ---------|-----| RD |----|-----| Client | 146 +----+ | ----| | | +--------+ 147 --|- +------+ | 148 +----+ ---- | | 149 | EP |---- | | 150 +----+ 152 Figure 1: The resource directory architecture. 154 2.1. Use Case: Cellular M2M 156 Over the last few years, mobile operators around the world have 157 focused on development of M2M solutions in order to expand the 158 business to the new type of users, i.e. machines. The machines are 159 connected directly to a mobile network using appropriate embedded air 160 interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing short and 161 wide range wireless interfaces. From the system design point of 162 view, the ambition is to design horizontal solutions that can enable 163 utilization of machines in different applications depending on their 164 current availability and capabilities as well as application 165 requirements, thus avoiding silo like solutions. One of the crucial 166 enablers of such design is the ability to discover resources 167 (machines - End Points) capable of providing required information at 168 a given time or acting on instructions from the end users. 170 In a typical scenario, during a boot-up procedure (and periodically 171 afterwards), the machines (EPs) register with a Resource Directory 172 (for example EPs installed on vehicles enabling tracking of their 173 position for the fleet management purposes and monitoring environment 174 parameters) hosted by the mobile operator or somewhere else in the 175 network, submiting a description of own capabilities. Due to the 176 usual network configuration of mobile networks, the EPs attached to 177 the mobile network do not have routable addresses. Therefore, a 178 remote server is usually used to provide proxy access to the EPs. 179 The address of each (proxy) EP on this server is included in the 180 resource description stored in the RD. The users, for example mobile 181 applications for environment monitoring, contact the RD, look-up the 182 EPs capable of providing information about the environment using 183 appropriate set of tags, obtain information on how to contact them 184 (URLs of the proxy server) and then initate interaction to obtain 185 information that is finally processed, displayed on the screen and 186 usually stored in a database. Similarly, fleet management systems 187 provide a set of credentials along with the appropriate tags to the 188 RD to look-up for EPs deployed on the vehicles the application is 189 responsible for. 191 2.2. Use Case: Home and Building Automation 193 Home and commercial building automation systems can benefit from the 194 use of M2M web services. The use of CoRE in home automation across 195 multiple subnets is described in [I-D.brandt-coap-subnet-discovery] 196 and in commercial building automation in [I-D.vanderstok-core-bc]. 197 The discovery requirements of these applications are demanding. Home 198 automation usually relies on run-time discovery to commision the 199 system, whereas in building automation a combination of professional 200 commissioning and run-time discovery. Both home and building 201 automation involve peer-to-peer interactions between end-points, and 202 involve battery-powered sleeping devices. 204 The exporting of resource information to other discovery systems is 205 also important in these automation applications. In home automation 206 there is a need to interact with other consumer electronics, which 207 may already support DNS-SD, and in building automation larger 208 resource directories or DNS-SD covering multiple buildings. 210 3. Resource Directory Interfaces 212 This section defines the REST interfaces between an RD and end- 213 points, and a lookup interface between an RD and clients. Although 214 the examples throughout this section assume use of CoAP 215 [I-D.ietf-core-coap], these REST interfaces can also be realized 216 using HTTP [RFC2616]. An RD implementing this specification MUST 217 support the discovery, registration, update, removal and lookup 218 interfaces defined in this section and MAY support the validation 219 interface. For the purpose of validation, an end-point implementing 220 this specification SHOULD support Etag validation on /.well-known/ 221 core. 223 3.1. Discovery 225 Before an end-point can make use of an RD, it must first know its 226 location and optionally the path of the RD root resource. There can 227 be several mechanisms for discovering the RD including assuming a 228 default location (e.g. on an Edge Router in a LoWPAN), by assigning 229 an anycast address to the RD, using DHCP, or by discovering the RD 230 using the CoRE Link Format. This section defines discovery of the RD 231 using the well-known interface of the CoRE Link Format 232 [I-D.ietf-core-link-format] as the required mechanism. It is however 233 expected that RDs will also be discoverable via other methods 234 depending on the deployment. 236 Discovery is performed by sending either a multicast or unicast GET 237 request to /.well-known/core and including a Resource Type (rt) 238 parameter [I-D.ietf-core-link-format] with the value "core-rd" in the 239 query string. Upon success, the response will contain a payload with 240 a link format entry for each RD discovered, with the URL indicating 241 the root resource of the RD. When performing multicast discovery, 242 the multicast IP address used will depend on the scope required and 243 the multicast capabilities of the network (TBD if a specific 244 multicast address should be defined for RDs). 246 An RD implementing this specification MUST support query filtering 247 for the rt parameter as defined in [I-D.ietf-core-link-format]. 249 The discovery interface is specified as follows: 251 Interaction: EP -> RD 253 Path: /.well-known/core 255 Method: GET 257 Content-Type: application/link-format (if any) 259 Parameters: 261 Resource Type (rt): MUST contain the value "core-rd" 263 Success: 2.05 "Content" with an application/link-format payload 264 containing a matching entry for the RD resource. 266 Failure: 2.05 "Content" (should be a "No Content" code?) with an 267 empty payload is returned in case no matching entry is found for a 268 unicast request. 270 Failure: No error response to a multicast request. 272 Failure: 4.00 "Bad Request" 274 The following example shows an end-point discovering an RD using this 275 interface, thus learning that the base RD resource is at /rd. Note 276 that it is up to the RD to choose its base RD resource. 278 End-point RD 279 | | 280 | ----- GET /.well-known/core?rt=core-rd ------> | 281 | | 282 | | 283 | <---- 2.05 Content "; rt="core-rd" ------ | 284 | | 286 Req: GET coap://[ff02::1]/.well-known/core?rt=core-rd 288 Res: 2.05 Content 289 ; rt="core-rd" 291 3.2. Registration 293 After discovering the location of an RD, an end-point MAY register 294 its resources to the RD's registration interface. This interface 295 accepts a POST from an end-point containing the list of resources to 296 be added to the directory as the message payload in the CoRE Link 297 Format along with query string parameters indicating the name of the 298 end-point, an optional node identifier and the lifetime of the 299 registration. The RD then creates a new resource or updates an 300 existing resource in the RD and returns its location. An end-point 301 MUST use that location when refreshing registrations using this 302 interface. End-point resources in the RD are kept active for the 303 period indicated by the lifetime parameter. The end-point is 304 reponsible for refreshing the entry within this period using either 305 the registration or update interface. 307 The registration interface is specified as follows: 309 Interaction: EP -> RD 311 Path: /.well-known/core or /{rd-base} 313 Method: POST 315 Content-Type: application/link-format 317 Etag: The Etag option MUST be included to allow an RD to perform 318 validation in the future. 320 Parameters: 322 End-point Name (n): Name of the end-point, MUST be unique within 323 this domain. If no end-point name is included, the RD SHOULD 324 generate a unique name for the end-point. The maximum length 325 of this parameter is 63 octets. 327 Node Identifier (id): An optional unique identifier for the node 328 hosting the end-point (e.g. a serial number, EUI-64, UUID or 329 iNumber). 331 Lifetime (lt): Lifetime of the registration in seconds. Range of 332 60-4294967295. If no lifetime is included, a default value of 333 86400 (24 hours) SHOULD be assumed. 335 Success: 2.01 "Created". The Location header of the new resource 336 entry for the end-point could be e.g. in the form /{rd-base}/ 337 {end-point name} 339 Failure: 4.00 "Bad Request". Malformed request. 341 Failure: 5.03 "Service Unavailable". Service could not perform the 342 operation. 344 The following example shows an end-point with the name "node1" 345 registering two resources to an RD using this interface. 347 End-point RD 348 | | 349 | --- POST /rd " | 350 | | 351 | | 352 | <-- 2.01 Created Location: /rd/node1 --------- | 353 | | 355 Req: POST coap://rd.example.org/rd?n=node1<=1024 356 Etag: 0x3f 357 Payload: 358 ;ct=41;rt="TemperatureC";if="sensor", 359 ;ct=41;rt="LightLux";if="sensor" 361 Res: 2.01 Created 362 Location: /rd/node1 364 3.3. Update 366 The update interface is used by an end-point to refresh or update its 367 registration with an RD. To use the interface, the end-point sends a 368 PUT request to the resource returned in the Location option in the 369 response to the first registration. An update MAY contain a payload 370 in CoRE Link Format if there have been changes since the last 371 registration or update. 373 The update interface is specified as follows: 375 Interaction: EP -> RD 377 Path: Location returned by registration. 379 Method: PUT 381 Content-Type: application/link-format (if any) 383 Etag: The Etag option MUST be included to allow an RD to compare the 384 existing entry and perform validation in the future. 386 Parameters: 388 Lifetime (lt): Lifetime of the registration in seconds. Range of 389 60-4294967295. If no lifetime is included, a default value of 390 86400 (24 hours) SHOULD be assumed. 392 Success: 2.04 "Changed" in case the resource and/or lifetime was 393 successfully updated 395 Failure: 4.00 "Bad Request". Malformed request. 397 Failure: 5.03 "Service Unavailable". Service could not perform the 398 operation. 400 The following example shows an end-point updating a new set of 401 resources to an RD using this interface. 403 End-point RD 404 | | 405 | --- PUT /rd/node1 " | 406 | | 407 | | 408 | <-- 2.04 Changed ---------------------------- | 409 | | 411 Req: PUT /rd/node1 412 Etag: 0x40 413 Payload: 414 ;ct=41;ins="Indoor";rt="TemperatureC";if="sensor", 415 ;ct=41;ins="Outdoor";rt="TemperatureC";if="sensor", 416 ;ct=41;rt="LightLux";if="sensor" 418 Res: 2.04 Changed 420 3.4. Validation 422 In some cases, an RD may want to validate that it has the latest 423 version of an end-point's resource. This can be performed with a GET 424 on the well-known interface of the CoRE Link Format including the 425 latest Etag stored for that end-point. For the purpose of 426 validation, an end-point implementing this specification SHOULD 427 support Etag validation on /.well-known/core. 429 The validation interface is specified as follows: 431 Interaction: RD -> EP 433 Path: /.well-known/core 435 Method: GET 437 Content-Type: application/link-format (if any) 439 Etag: The Etag option MUST be included 441 Parameters: None 443 Success: 2.03 "Valid" in case the Etag matches 445 Success: 2.05 "Content" in case the Etag does not match, the 446 response MUST include the most recent resource representation and 447 its corresponding Etag. 449 Failure: 4.00 "Bad Request". Malformed request. 451 The following examples shows a successful validation. 453 End-point RD 454 | | 455 | <--- GET /.well-known/core Etag: 0x40 -------- | 456 | | 457 | | 458 | --- 2.03 Valid -----------------------------> | 459 | | 461 Req: GET coap://{end-point}/.well-known/core 462 Etag: 0x40 464 Res: 2.03 Valid 466 3.5. Removal 468 Although RD entries have soft state and will eventually timeout after 469 their lifetime, an end-point SHOULD explicitly remove its entry from 470 the RD if it knows it will no longer be available (for example on 471 shut-down). This is accomplished using a removal interface on the RD 472 by performing a DELETE on the end-point resource. 474 The removal interface is specified as follows: 476 Interaction: EP -> RD 478 Path: Location returned by registration. 480 Method: DELETE 482 Content-Type: None 484 Parameters: None 486 Success: 2.02 "Deleted" upon successful deletion 488 Failure: 4.00 "Bad Request". Malformed request. 490 Failure: 5.03 "Service Unavailable". Service could not perform the 491 operation. 493 The following examples shows successful removal of the end-point from 494 the RD. 496 End-point RD 497 | | 498 | --- DELETE /rd/node1 -----------------------> | 499 | | 500 | | 501 | <-- 2.02 Deleted ---------------------------- | 502 | | 504 Req: DELETE /rd/node1 506 Res: 2.02 Deleted 508 3.6. Lookup 510 In order for an RD to be used for discovering resources registered 511 with it, a lookup interface is provided. This lookup interface is 512 provided as a default, and it is assumed that RDs may also support 513 lookups to return resource descriptions in alternative formats (e.g. 514 Atom or HTML Link) or using more advanced interfaces (e.g. supporting 515 context or semantic based lookup). 517 The lookup interface is provided using the CoRE Link Format 518 [I-D.ietf-core-link-format] resource discovery mechanism on the root 519 RD resource (/rd in the examples). The scope of the discovery is 520 controlled by the depth of the resource the query is made on. A 521 lookup on the root RD resource /rd queries all resource descriptions 522 on the RD, whereas a lookup on /rd/node1 queries all resource 523 descriptions held in the "node1" entry. An RD MUST support the query 524 filtering defined in [I-D.ietf-core-link-format] to allow for 525 filtered lookups. 527 The lookup interface is specified as follows: 529 Interaction: Client -> RD 531 Path: /{rd-base} or e.g. /{rd-base}/{end-point name} 533 Method: GET 535 Content-Type: application/link-format (if any) 536 Parameters: 538 Filtering: CoRE Link Format attributes may be included to filter 539 the lookup. 541 Success: 2.05 "Content" with an application/link-format payload 542 containing a matching entries for the lookup. 544 Failure: 2.05 "Content" (should be a "No Content" code?) with an 545 empty payload is returned in case no matching entry is found for a 546 unicast request. 548 Failure: No error response to a multicast request. 550 Failure: 4.00 "Bad Request". Malformed request. 552 Failure: 5.03 "Service Unavailable". Service could not perform the 553 operation. 555 The following example shows a client performing a lookup on an RD 556 using this interface. 558 Client RD 559 | | 560 | ----- GET /rd?rt=Temperature ----------------------------> | 561 | | 562 | | 563 | <-- 2.05 Content ";rt="Temperature" ---- | 564 | | 566 Req: GET /rd?rt=Temperature 568 Res: 2.05 Content 569 ;rt="Temperature" 571 4. New Link-Format Attributes 573 When using the CoRE Link Format to describe resources being 574 discovered by or posted to a resource directory service, additional 575 information about those resources is useful. This specification 576 defines the following new attributes for use in the CoRE Link Format 577 [I-D.ietf-core-link-format]: 579 link-extension = ( "ins" "=" quoted-string ) ; Max 63 octets 580 link-extension = ( "exp" ) 582 4.1. Resource Instance 'ins' attribute 584 The Resource Instance "ins" attribute is an identifier for this 585 resource, which makes it possible to distinguish from other similar 586 resources. This attribute is similar in use to the "Instance" 587 portion of a DNS-SD record, and SHOULD be unique across resources 588 with the same Resource Type attribute in the domain it is used. A 589 Resource Instance might be a descriptive string like "Ceiling Light, 590 Room 3", a short ID like "AF39" or a unique UUID or iNumber. This 591 attribute is used by a Resource Directory to distinguish between 592 multiple instances of the same resource type within a system. 594 This attribute MUST be no more than 63 octets in length. The 595 resource identifier attribute MUST NOT appear more than once in a 596 link description. 598 4.2. Export 'exp' attribute 600 The Export "exp" attribute is used as a flag to indicate that a link 601 description MAY be exported by a resource directory to external 602 directories. 604 The CoRE Link Format is used for many purposes between CoAP end- 605 points. Some are useful mainly locally, for example checking the 606 observability of a resource before accessing it, determining the size 607 of a resource, or traversing dynamic resource structures. However, 608 other links are very useful to be exported to other directories, for 609 example the entry point resource to a functional service. 611 5. Security Considerations 613 This document needs the same security considerations as described in 614 Section 7 of [RFC5988] and Section 6 of [I-D.ietf-core-link-format]. 615 The /.well-known/core resource may be protected e.g. using DTLS when 616 hosted on a CoAP server as described in [I-D.ietf-core-coap]. 618 6. IANA Considerations 620 "core-rd" resource type needs to be registered if an appropriate 621 registry is created. 623 "ins" and "exp" attributes need to be registered when a future Web 624 Linking attribute is created. 626 7. Acknowledgments 628 Szymon Sasin, Carsten Bormann, Kerry Lynn, Peter van der Stok, Anders 629 Brandt and Linyi Tian have provided helpful comments, discussions and 630 ideas to improve and shape this document. The authors would also 631 like to thank their collagues from the EU FP7 SENSEI project, where 632 many of the resource directory concepts were originally developed. 634 8. Changelog 636 9. References 638 9.1. Normative References 640 [I-D.ietf-core-link-format] 641 Shelby, Z., "CoRE Link Format", 642 draft-ietf-core-link-format-06 (work in progress), 643 June 2011. 645 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 647 9.2. Informative References 649 [I-D.brandt-coap-subnet-discovery] 650 Brandt, A., "Discovery of CoAP servers across subnets", 651 draft-brandt-coap-subnet-discovery-00 (work in progress), 652 March 2011. 654 [I-D.ietf-core-coap] 655 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 656 "Constrained Application Protocol (CoAP)", 657 draft-ietf-core-coap-06 (work in progress), May 2011. 659 [I-D.shelby-core-coap-req] 660 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 661 Kelsey, "CoAP Requirements and Features", 662 draft-shelby-core-coap-req-01 (work in progress), 663 April 2010. 665 [I-D.vanderstok-core-bc] 666 Stok, P. and K. Lynn, "CoAP Utilization for Building 667 Control", draft-vanderstok-core-bc-03 (work in progress), 668 March 2011. 670 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 671 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 672 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 674 Authors' Addresses 676 Zach Shelby 677 Sensinode 678 Kidekuja 2 679 Vuokatti 88600 680 FINLAND 682 Phone: +358407796297 683 Email: zach@sensinode.com 685 Srdjan Krco 686 Ericsson 688 Phone: 689 Email: srdjan.krco@ericsson.com