idnits 2.17.1 draft-shelby-core-resource-directory-01.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...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 15, 2011) is 4604 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: March 18, 2012 Ericsson 6 September 15, 2011 8 CoRE Resource Directory 9 draft-shelby-core-resource-directory-01 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 March 18, 2012. 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 . . . . . . . . . . . . . . . . . . 14 70 4.1. Resource Instance 'ins' attribute . . . . . . . . . . . . 14 71 4.2. Export 'exp' attribute . . . . . . . . . . . . . . . . . . 14 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 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 Instance (ins): Used to differentiate between multiple RDs. 265 Success: 2.05 "Content" with an application/link-format payload 266 containing a matching entry for the RD resource. 268 Failure: 2.05 "Content" (should be a "No Content" code?) with an 269 empty payload is returned in case no matching entry is found for a 270 unicast request. 272 Failure: No error response to a multicast request. 274 Failure: 4.00 "Bad Request" 276 The following example shows an end-point discovering an RD using this 277 interface, thus learning that the base RD resource is at /rd. Note 278 that it is up to the RD to choose its base RD resource. 280 End-point RD 281 | | 282 | ----- GET /.well-known/core?rt=core-rd ------> | 283 | | 284 | | 285 | <---- 2.05 Content "; rt="core-rd" ------ | 286 | | 288 Req: GET coap://[ff02::1]/.well-known/core?rt=core-rd 290 Res: 2.05 Content 291 ; rt="core-rd"; ins="Primary" 293 3.2. Registration 295 After discovering the location of an RD, an end-point MAY register 296 its resources to the RD's registration interface. This interface 297 accepts a POST from an end-point containing the list of resources to 298 be added to the directory as the message payload in the CoRE Link 299 Format along with query string parameters indicating the name of the 300 end-point, an optional node identifier and the lifetime of the 301 registration. The end-point name is formed by concatenating the Host 302 and Instance parameters included with the registration. All 303 parameters of the registration are optional. In the absense of a 304 Host parameter, the RD will generate a unique one on behalf of the 305 end-point. The RD then creates a new resource or updates an existing 306 resource in the RD and returns its location. An end-point MUST use 307 that location when refreshing registrations using this interface. 309 End-point resources in the RD are kept active for the period 310 indicated by the lifetime parameter. The end-point is reponsible for 311 refreshing the entry within this period using either the registration 312 or update interface. 314 The registration interface is specified as follows: 316 Interaction: EP -> RD 318 Path: /.well-known/core or /{rd-base} 320 Method: POST 322 Content-Type: application/link-format 324 Etag: The Etag option MUST be included to allow an RD to perform 325 validation in the future. 327 Parameters: 329 Lifetime (lt): Lifetime of the registration in seconds. Range of 330 60-4294967295. If no lifetime is included, a default value of 331 86400 (24 hours) SHOULD be assumed. 333 Host (h): The host identifier or name of the registering node. 334 The maximum length of this parameter is 63 octets. This 335 parameter is combined with the Instance parameter (if any) to 336 form the end-point name. If not included, the RD MUST generate 337 a unique Host name on behalf of the node. 339 Instance (ins): The instance of the end-point on this host, if 340 there are multiple. The maximum length of this parameter is 63 341 octets. 343 Type (rt): The semantic type of end-point. The maximum length of 344 this parameter is 63 octets. 346 Success: 2.01 "Created". The Location header of the new resource 347 entry for the end-point could be e.g. in the form /{rd-base}/ 348 {end-point name} 350 Failure: 4.00 "Bad Request". Malformed request. 352 Failure: 5.03 "Service Unavailable". Service could not perform the 353 operation. 355 The following example shows an end-point with the name "node1" 356 registering two resources to an RD using this interface. 358 End-point RD 359 | | 360 | --- POST /rd " | 361 | | 362 | | 363 | <-- 2.01 Created Location: /rd/node1 --------- | 364 | | 366 Req: POST coap://rd.example.org/rd?h=node1<=1024 367 Etag: 0x3f 368 Payload: 369 ;ct=41;rt="TemperatureC";if="sensor", 370 ;ct=41;rt="LightLux";if="sensor" 372 Res: 2.01 Created 373 Location: /rd/node1 375 3.3. Update 377 The update interface is used by an end-point to refresh or update its 378 registration with an RD. To use the interface, the end-point sends a 379 PUT request to the resource returned in the Location option in the 380 response to the first registration. An update MAY contain a payload 381 in CoRE Link Format if there have been changes since the last 382 registration or update. 384 The update interface is specified as follows: 386 Interaction: EP -> RD 388 Path: Location returned by registration. 390 Method: PUT 392 Content-Type: application/link-format (if any) 394 Etag: The Etag option MUST be included to allow an RD to compare the 395 existing entry and perform validation in the future. 397 Parameters: 399 Lifetime (lt): Lifetime of the registration in seconds. Range of 400 60-4294967295. If no lifetime is included, a default value of 401 86400 (24 hours) SHOULD be assumed. 403 Success: 2.04 "Changed" in case the resource and/or lifetime was 404 successfully updated 406 Failure: 4.00 "Bad Request". Malformed request. 408 Failure: 5.03 "Service Unavailable". Service could not perform the 409 operation. 411 The following example shows an end-point updating a new set of 412 resources to an RD using this interface. 414 End-point RD 415 | | 416 | --- PUT /rd/node1 " | 417 | | 418 | | 419 | <-- 2.04 Changed ---------------------------- | 420 | | 422 Req: PUT /rd/node1 423 Etag: 0x40 424 Payload: 425 ;ct=41;ins="Indoor";rt="TemperatureC";if="sensor", 426 ;ct=41;ins="Outdoor";rt="TemperatureC";if="sensor", 427 ;ct=41;rt="LightLux";if="sensor" 429 Res: 2.04 Changed 431 3.4. Validation 433 In some cases, an RD may want to validate that it has the latest 434 version of an end-point's resource. This can be performed with a GET 435 on the well-known interface of the CoRE Link Format including the 436 latest Etag stored for that end-point. For the purpose of 437 validation, an end-point implementing this specification SHOULD 438 support Etag validation on /.well-known/core. 440 The validation interface is specified as follows: 442 Interaction: RD -> EP 444 Path: /.well-known/core 445 Method: GET 447 Content-Type: application/link-format (if any) 449 Etag: The Etag option MUST be included 451 Parameters: None 453 Success: 2.03 "Valid" in case the Etag matches 455 Success: 2.05 "Content" in case the Etag does not match, the 456 response MUST include the most recent resource representation and 457 its corresponding Etag. 459 Failure: 4.00 "Bad Request". Malformed request. 461 The following examples shows a successful validation. 463 End-point RD 464 | | 465 | <--- GET /.well-known/core Etag: 0x40 -------- | 466 | | 467 | | 468 | --- 2.03 Valid -----------------------------> | 469 | | 471 Req: GET coap://{end-point}/.well-known/core 472 Etag: 0x40 474 Res: 2.03 Valid 476 3.5. Removal 478 Although RD entries have soft state and will eventually timeout after 479 their lifetime, an end-point SHOULD explicitly remove its entry from 480 the RD if it knows it will no longer be available (for example on 481 shut-down). This is accomplished using a removal interface on the RD 482 by performing a DELETE on the end-point resource. 484 The removal interface is specified as follows: 486 Interaction: EP -> RD 487 Path: Location returned by registration. 489 Method: DELETE 491 Content-Type: None 493 Parameters: None 495 Success: 2.02 "Deleted" upon successful deletion 497 Failure: 4.00 "Bad Request". Malformed request. 499 Failure: 5.03 "Service Unavailable". Service could not perform the 500 operation. 502 The following examples shows successful removal of the end-point from 503 the RD. 505 End-point RD 506 | | 507 | --- DELETE /rd/node1 -----------------------> | 508 | | 509 | | 510 | <-- 2.02 Deleted ---------------------------- | 511 | | 513 Req: DELETE /rd/node1 515 Res: 2.02 Deleted 517 3.6. Lookup 519 In order for an RD to be used for discovering resources registered 520 with it, a lookup interface is provided. This lookup interface is 521 provided as a default, and it is assumed that RDs may also support 522 lookups to return resource descriptions in alternative formats (e.g. 523 Atom or HTML Link) or using more advanced interfaces (e.g. supporting 524 context or semantic based lookup). 526 The lookup interface is provided using the CoRE Link Format 527 [I-D.ietf-core-link-format] resource discovery mechanism on the root 528 RD resource (/rd in the examples). The scope of the discovery is 529 controlled by the depth of the resource the query is made on. A 530 lookup on the root RD resource /rd queries all resource descriptions 531 on the RD, whereas a lookup on /rd/node1 queries all resource 532 descriptions held in the "node1" entry. An RD MUST support the query 533 filtering defined in [I-D.ietf-core-link-format] to allow for 534 filtered lookups. 536 The lookup interface is specified as follows: 538 Interaction: Client -> RD 540 Path: /{rd-base} or e.g. /{rd-base}/{end-point} 542 Method: GET 544 Content-Type: application/link-format (if any) 546 Parameters: 548 Filtering: CoRE Link Format attributes may be included to filter 549 the lookup. 551 Success: 2.05 "Content" with an application/link-format payload 552 containing a matching entries for the lookup. 554 Failure: 2.05 "Content" (should be a "No Content" code?) with an 555 empty payload is returned in case no matching entry is found for a 556 unicast request. 558 Failure: No error response to a multicast request. 560 Failure: 4.00 "Bad Request". Malformed request. 562 Failure: 5.03 "Service Unavailable". Service could not perform the 563 operation. 565 The following example shows a client performing a lookup on an RD 566 using this interface. 568 Client RD 569 | | 570 | ----- GET /rd/node1?rt=Temperature ----------------------> | 571 | | 572 | | 573 | <-- 2.05 Content ";rt="Temperature" ---- | 574 | | 576 Req: GET /rd/node1?rt=Temperature 578 Res: 2.05 Content 579 ;rt="Temperature" 581 4. New Link-Format Attributes 583 When using the CoRE Link Format to describe resources being 584 discovered by or posted to a resource directory service, additional 585 information about those resources is useful. This specification 586 defines the following new attributes for use in the CoRE Link Format 587 [I-D.ietf-core-link-format]: 589 link-extension = ( "ins" "=" quoted-string ) ; Max 63 octets 590 link-extension = ( "exp" ) 592 4.1. Resource Instance 'ins' attribute 594 The Resource Instance "ins" attribute is an identifier for this 595 resource, which makes it possible to distinguish from other similar 596 resources. This attribute is similar in use to the "Instance" 597 portion of a DNS-SD record, and SHOULD be unique across resources 598 with the same Resource Type attribute in the domain it is used. A 599 Resource Instance might be a descriptive string like "Ceiling Light, 600 Room 3", a short ID like "AF39" or a unique UUID or iNumber. This 601 attribute is used by a Resource Directory to distinguish between 602 multiple instances of the same resource type within a system. 604 This attribute MUST be no more than 63 octets in length. The 605 resource identifier attribute MUST NOT appear more than once in a 606 link description. 608 4.2. Export 'exp' attribute 610 The Export "exp" attribute is used as a flag to indicate that a link 611 description MAY be exported by a resource directory to external 612 directories. 614 The CoRE Link Format is used for many purposes between CoAP end- 615 points. Some are useful mainly locally, for example checking the 616 observability of a resource before accessing it, determining the size 617 of a resource, or traversing dynamic resource structures. However, 618 other links are very useful to be exported to other directories, for 619 example the entry point resource to a functional service. 621 5. Security Considerations 623 This document needs the same security considerations as described in 624 Section 7 of [RFC5988] and Section 6 of [I-D.ietf-core-link-format]. 625 The /.well-known/core resource may be protected e.g. using DTLS when 626 hosted on a CoAP server as described in [I-D.ietf-core-coap]. 628 6. IANA Considerations 630 "core-rd" resource type needs to be registered if an appropriate 631 registry is created. 633 "ins" and "exp" attributes need to be registered when a future Web 634 Linking attribute is created. 636 7. Acknowledgments 638 Szymon Sasin, Carsten Bormann, Kerry Lynn, Peter van der Stok, Anders 639 Brandt and Linyi Tian have provided helpful comments, discussions and 640 ideas to improve and shape this document. The authors would also 641 like to thank their collagues from the EU FP7 SENSEI project, where 642 many of the resource directory concepts were originally developed. 644 8. Changelog 646 9. References 648 9.1. Normative References 650 [I-D.ietf-core-link-format] 651 Shelby, Z., "CoRE Link Format", 652 draft-ietf-core-link-format-06 (work in progress), 653 June 2011. 655 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. 657 9.2. Informative References 659 [I-D.brandt-coap-subnet-discovery] 660 Brandt, A., "Discovery of CoAP servers across subnets", 661 draft-brandt-coap-subnet-discovery-00 (work in progress), 662 March 2011. 664 [I-D.ietf-core-coap] 665 Shelby, Z., Hartke, K., Bormann, C., and B. Frank, 666 "Constrained Application Protocol (CoAP)", 667 draft-ietf-core-coap-06 (work in progress), May 2011. 669 [I-D.shelby-core-coap-req] 670 Shelby, Z., Stuber, M., Sturek, D., Frank, B., and R. 671 Kelsey, "CoAP Requirements and Features", 672 draft-shelby-core-coap-req-01 (work in progress), 673 April 2010. 675 [I-D.vanderstok-core-bc] 676 Stok, P. and K. Lynn, "CoAP Utilization for Building 677 Control", draft-vanderstok-core-bc-03 (work in progress), 678 March 2011. 680 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 681 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 682 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 684 Authors' Addresses 686 Zach Shelby 687 Sensinode 688 Kidekuja 2 689 Vuokatti 88600 690 FINLAND 692 Phone: +358407796297 693 Email: zach@sensinode.com 695 Srdjan Krco 696 Ericsson 698 Phone: 699 Email: srdjan.krco@ericsson.com