idnits 2.17.1 draft-hartke-t2trg-coral-reef-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 : ---------------------------------------------------------------------------- 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 (March 11, 2019) is 1874 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'I-D.hartke-t2trg-coral-reef' is mentioned on line 911, but not defined == Outdated reference: A later version (-09) exists of draft-hartke-t2trg-coral-08 == Outdated reference: A later version (-11) exists of draft-nottingham-rfc5785bis-09 == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-19 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Thing-to-Thing Research Group K. Hartke 3 Internet-Draft Ericsson 4 Intended status: Experimental March 11, 2019 5 Expires: September 12, 2019 7 Resource Discovery in Constrained RESTful Environments (CoRE) 8 Using the Constrained RESTful Application Language (CoRAL) 9 draft-hartke-t2trg-coral-reef-01 11 Abstract 13 This document explores how the Constrained RESTful Application 14 Language (CoRAL) might be used for two use cases in Constrained 15 RESTful Environments (CoRE): CoRE Resource Discovery, which allows a 16 client to discover the resources of a server given a host name or IP 17 address, and CoRE Resource Directory, which provides a directory of 18 resources on many servers. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 12, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Resource Discovery . . . . . . . . . . . . . . . . . . . 3 57 2.2. Resource Directory . . . . . . . . . . . . . . . . . . . 5 58 2.3. Notational Conventions . . . . . . . . . . . . . . . . . 6 59 3. Resource Metadata . . . . . . . . . . . . . . . . . . . . . . 6 60 4. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 8 62 4.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 9 64 4.2.2. Get Resources By Resource Type . . . . . . . . . . . 10 65 4.2.3. Get Resources By Interface Type . . . . . . . . . . . 11 66 5. Resource Directory . . . . . . . . . . . . . . . . . . . . . 12 67 5.1. How It Works . . . . . . . . . . . . . . . . . . . . . . 12 68 5.2. API Reference . . . . . . . . . . . . . . . . . . . . . . 13 69 5.2.1. Get All Resources . . . . . . . . . . . . . . . . . . 13 70 5.2.2. Get Resources By Resource Type . . . . . . . . . . . 14 71 5.2.3. Get Resources By Interface Type . . . . . . . . . . . 15 72 5.2.4. List Resource Registrations . . . . . . . . . . . . . 16 73 5.2.5. Create Resource Registration . . . . . . . . . . . . 17 74 5.2.6. Read Resource Registration . . . . . . . . . . . . . 18 75 5.2.7. Update Resource Registration . . . . . . . . . . . . 19 76 5.2.8. Delete Resource Registration . . . . . . . . . . . . 20 77 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 78 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 79 7.1. CoRE Dictionary . . . . . . . . . . . . . . . . . . . . . 21 80 7.2. CoAP Content Format . . . . . . . . . . . . . . . . . . . 23 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 82 8.1. Normative References . . . . . . . . . . . . . . . . . . 23 83 8.2. Informative References . . . . . . . . . . . . . . . . . 24 84 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 25 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 87 1. Preamble 89 This document explores how CoRE Resource Discovery [RFC6690] and CoRE 90 Resource Directory [I-D.ietf-core-resource-directory] might look like 91 if based on CoRAL [I-D.hartke-t2trg-coral]. The exploration is done 92 in the style of a self-contained specification. 94 This document doesn't represent a proposal or recommendation for 95 standardization at its current stage. 97 2. Introduction 99 Constrained RESTful Environments (CoRE) realize the Representational 100 State Transfer (REST) architectural style [REST] in a suitable form 101 for constrained nodes (e.g., 8-bit microcontrollers with limited RAM 102 and ROM) and constrained networks [RFC7228]. CoRE technologies like 103 the Constrained Application Protocol (CoAP) [RFC7252] are aimed at 104 machine-to-machine (M2M) applications like smart energy and building 105 automation. 107 The discovery of resources hosted by a constrained server is very 108 important in machine-to-machine applications where there are no 109 humans in the loop and static interfaces result in fragility. In the 110 Web, the discovery of resources provided by a Web server is typically 111 based on links in representations of resources pointing at other 112 resources, with search engines providing an entry point to find 113 resources based on queries. 115 This document applies the idea of using Web Linking [RFC8288] for 116 discovery to Constrained RESTful Environments. The discovery of 117 resources hosted by a constrained Web server, resource metadata, and 118 related resources is called "CoRE Resource Discovery". 120 The main function of CoRE Resource Discovery is to provide Uniform 121 Resource Identifiers (URIs) [RFC3986] for the resources hosted by a 122 server, complemented by metadata about those resources and possibly 123 links to further resources. In this document, this information is 124 conveyed in the Constrained RESTful Application Language (CoRAL) 125 [I-D.hartke-t2trg-coral]. 127 This document specifies the use of CoRAL for two use cases: 129 Resource Discovery 130 Allows a client to discover the resources of a server given a host 131 name or IP address. 133 Resource Directory 134 Allows a client to discover the resources of several servers given 135 the URL of a resource directory. 136 Allows a server (or a third party acting on behalf of a server) to 137 register resources with a resource directory given a URL. 139 2.1. Resource Discovery 141 In many M2M applications, such as home or building automation, there 142 is a need for local clients and servers to find and interact with 143 each other without human intervention. CoRE Resource Discovery can 144 be used by clients in such environments to discover the resources 145 hosted by the server given a host name or IP address. 147 In this specification, this is performed by retrieving a CoRAL 148 representation of a well-known resource on the server, called 149 "/.well-known/core". The representation contains a list of links to 150 the resources of interest on the server, which are typically entry 151 points to the different applications hosted by the server. The links 152 may have nested resource metadata. A client would then find an 153 appropriate resource based on the metadata. Metadata queries may 154 also be specified the query string to filter the result set. 156 The following example shows how a client discovers the resources of a 157 CoAP server by making a GET request to the "/.well-known/core" 158 resource. The client receives a 2.05 (Content) response with a list 159 of links of type . The links contain nested 160 elements with resource metadata (such as resource type, interface 161 description, available content formats, and related resources). 163 => 0.01 GET 164 Uri-Path: .well-known 165 Uri-Path: core 166 Accept: TBD3 168 <= 2.05 Content 169 Content-Format: TBD3 171 #using 172 #using iana = 174 rd-item { 175 ct 40 176 title "Sensor Index" 177 } 178 rd-item { 179 rt "temperature-c" 180 if "sensor" 181 iana:describedby 182 iana:alternate 183 } 184 rd-item { 185 rt "light-lux" 186 if "sensor" 187 } 189 In detail, this representation contains links to three resources of 190 interest on the server: , , and . 193 For , a content format hint ("ct") and a title ("title") 194 are provided as resource metadata. For as well as 195 , a resource type ("rt") and an interface description 196 ("if") are provided as resource metadata. Additionally, two links 197 are provided with further detail on : one to a schema 198 describing this resource ("describedby") and one to an substitute for 199 this resource ("alternate"). 201 2.2. Resource Directory 203 In many deployment scenarios, such as in constrained networks with 204 sleeping servers or in large M2M deployments with bandwidth limited 205 access networks, it is beneficial to deploy resource directory 206 entities that store links to resources stored on other servers. A 207 resource directory can be thought of as a limited search engine for 208 M2M resources. 210 In this specification, a resource directory provides the same lookup 211 interface as a "/.well-known/core" resource, except that it provides 212 links to resources on potentially many different servers. For 213 populating the resource directory, a registration interface is 214 offered. The registration interface is a collection resource with 215 the common operations of create, read, update, and delete. The items 216 of the collection are groups of links of type 217 that are to be made available in the lookup interface. 219 The following example shows how a client registers a group of links 220 with a CoAP resource directory by making a POST request to the 221 collection resource. The client receives a 2.01 (Created) response 222 with the location of the created collection item. The client can use 223 this location later to update the group of links or delete them from 224 the directory. 226 => 0.02 POST 227 Uri-Path: path 228 Uri-Path: to 229 Uri-Path: resource 230 Uri-Path: directory 231 Content-Format: TBD3 233 #using 235 #base 236 rd-item { rt "light-lux" ct 0 } 237 rd-item { rt "light-lux" ct 0 } 238 rd-item { rt "light-lux" ct 0 } 240 <= 2.01 Created 241 Location-Path: path 242 Location-Path: to 243 Location-Path: resource 244 Location-Path: directory 245 Location-Path: 42 247 The following example shows how a client performs a lookup on the 248 resource directory by making a GET request to the resource directory 249 resource. The client receives a 2.05 (Content) response with a 250 combined view of all groups of links registered earlier, filtered by 251 a query. 253 => 0.01 GET 254 Uri-Path: path 255 Uri-Path: to 256 Uri-Path: resource 257 Uri-Path: directory 258 Uri-Query: rt=light-lux 259 Accept: TBD3 261 <= 2.05 Content 262 Content-Format: TBD3 264 #using 266 #base 267 rd-item { rt "light-lux" } 269 #base 270 rd-item { rt "light-lux" ct 0 } 271 rd-item { rt "light-lux" ct 0 } 272 rd-item { rt "light-lux" ct 0 } 274 2.3. Notational Conventions 276 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 277 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 278 "OPTIONAL" in this document are to be interpreted as described in BCP 279 14 [RFC2119] [RFC8174] when, and only when, they appear in all 280 capitals, as shown here. 282 3. Resource Metadata 284 Both "/.well-known/core" resources and resource directories link to 285 resources of interest using the link relation 286 type. Metadata for these resources can be expressed by nesting 287 further links inside these links. 289 The following link relation types for resource metadata are defined: 291 292 The link target is a hint indicating what the (human-spoken) 293 language of the result of dereferencing the link context should 294 be. 296 297 The link target indicates the intended destination medium or media 298 for style information for the link context. 300 301 The link target is a label that it can be used as a human-readable 302 identifier for the link context. 304 The link can have a nested link containing language information. 306 307 The link target is a hint indicating what the media type of the 308 result of dereferencing the link context should be. 310 311 The link target is an application-specific semantic type of the 312 link context. 314 Multiple resource types can be specified, each as a link with the 315 resource type as link target. The link target MUST NOT contain 316 multiple resource types separated by white space. 318 319 The link target is a specific interface definition that can be 320 used to interact with the link context. 322 323 The link target is an indication of the maximum size of the 324 resource representation returned by performing a GET on the link 325 context. 327 328 The link target is a hint about the Content-Formats that the link 329 context returns. 331 4. Resource Discovery 333 Given a host name or IP address, a client can discover the resources 334 of a server implementing this section through the use of a well-known 335 resource [I-D.nottingham-rfc5785bis]. Well-known resources have a 336 path component that begins with "/.well-known/". This specification 337 defines a new well-known resource for CoRE Resource Discovery: 338 "/.well-known/core". 340 4.1. How It Works 342 A server implementing this specification offers a "/.well-known/core" 343 resource on the default port appropriate for the protocol for the 344 purpose of resource discovery. It is up to the server which of the 345 resources in its namespace are included; the "/.well-known/core" 346 resource is generally meant to provide entry points to applications 347 hosted by the server. 349 A client wishing to discover the resources of a server constructs an 350 initial URI from a template using the given host name or IP address. 351 It then retrieves a CoRAL representation, as specified in 352 [I-D.hartke-t2trg-coral]. The representation contains a list of 353 links, each from the well-known resource to one resource, along with 354 resource metadata. The client can filter the list using a number of 355 query parameters. 357 4.2. API Reference 359 4.2.1. Get All Resources 361 Request 363 Request Method: GET 365 URI Template: coap://{host-and-port}/.well-known/core 367 Accept Option: TBD3 369 Response 371 When successful, the server returns a 2.05 (Content) response with 372 a representation in content format TBD3 ('application/coral+cbor; 373 dictionary=http://TBD5/'). The representation MUST contain zero 374 or more links of type , each of which MUST 375 target a resource in the namespace of the server (same origin). 376 The links may have nested elements providing resource metadata. 378 Example 380 => 0.01 GET 381 Uri-Path: .well-known 382 Uri-Path: core 383 Accept: TBD3 385 <= 2.05 Content 386 Content-Format: TBD3 388 #using 389 #using iana = 391 rd-item { 392 ct 40 393 title "Sensor Index" 394 } 395 rd-item { 396 rt "temperature-c" 397 if "sensor" 398 iana:describedby 399 iana:alternate 400 } 401 rd-item { 402 rt "light-lux" 403 if "sensor" 404 } 406 4.2.2. Get Resources By Resource Type 408 Request 410 Request Method: GET 412 URI Template: coap://{host-and-port}/.well-known/core?rt={value} 414 Accept Option: TBD3 416 Response 418 When successful, same response kind as in Section 4.2.1. 420 Example 422 => 0.01 GET 423 Uri-Path: .well-known 424 Uri-Path: core 425 Uri-Query: rt=temperature-c 426 Accept: TBD3 428 <= 2.05 Content 429 Content-Format: TBD3 431 #using 432 #using iana = 434 rd-item { 435 rt "temperature-c" 436 if "sensor" 437 iana:describedby 438 iana:alternate 439 } 441 4.2.3. Get Resources By Interface Type 443 Request 445 Request Method: GET 447 URI Template: coap://{host-and-port}/.well-known/core?if={value} 449 Accept Option: TBD3 451 Response 453 When successful, same response kind as in Section 4.2.1. 455 Example 457 => 0.01 GET 458 Uri-Path: .well-known 459 Uri-Path: core 460 Uri-Query: if=sensor 461 Accept: TBD3 463 <= 2.05 Content 464 Content-Format: TBD3 466 #using 467 #using iana = 469 rd-item { 470 rt "temperature-c" 471 if "sensor" 472 iana:describedby 473 iana:alternate 474 } 475 rd-item { 476 rt "light-lux" 477 if "sensor" 478 } 480 5. Resource Directory 482 A resource directory provides information about entry points to 483 applications hosted by other servers. It is intended to make 484 discovery operations more efficient than performing a lookup on the 485 "/.well-known/core" of each of these servers. 487 5.1. How It Works 489 A client wishing to discover resources using a resource directory 490 needs to be configured with the URI of a resource directory or 491 acquire it through some discovery process. The client then retrieves 492 the representation as specified in [I-D.hartke-t2trg-coral]. The 493 resource directory serves a list of links, each from the resource 494 directory to one of the resources, along with the resource metadata. 495 The client can filter the list using a number of query parameters. 497 A device (or a third party acting on behalf of a device) can register 498 resources with a resource directory by submitting links to be created 499 at the directory. The directory uses the submitted links in two 500 ways: First, it includes those links in the results of client 501 queries. Second, it creates a resource containing the group of 502 submitted links, such that the device can easily update or delete the 503 whole group as a single unit. 505 5.2. API Reference 507 5.2.1. Get All Resources 509 Request 511 Request Method: GET 513 URI Template: {resource-directory-location} 515 Accept Option: TBD3 517 Response 519 When successful, same response kind as in Section 4.2.1. 521 Example 523 => 0.01 GET 524 Uri-Path: path 525 Uri-Path: to 526 Uri-Path: resource 527 Uri-Path: directory 528 Accept: TBD3 530 <= 2.05 Content 531 Content-Format: TBD3 533 #using 534 #using iana = 536 rd-item { 537 ct 40 538 title "Sensor Index" 539 } 540 rd-item { 541 rt "temperature-c" 542 if "sensor" 543 iana:describedby 544 iana:alternate 545 } 546 rd-item { 547 rt "light-lux" 548 if "sensor" 549 } 551 5.2.2. Get Resources By Resource Type 553 Request 555 Request Method: GET 557 URI Template: {resource-directory-location}?rt={value} 559 Accept Option: TBD3 561 Response 563 When successful, same response kind as in Section 4.2.1. 565 Example 567 => 0.01 GET 568 Uri-Path: path 569 Uri-Path: to 570 Uri-Path: resource 571 Uri-Path: directory 572 Uri-Query: rt=temperature-c 573 Accept: TBD3 575 <= 2.05 Content 576 Content-Format: TBD3 578 #using 579 #using iana = 581 rd-item { 582 rt "temperature-c" 583 if "sensor" 584 iana:describedby 585 iana:alternate 586 } 588 5.2.3. Get Resources By Interface Type 590 Request 592 Request Method: GET 594 URI Template: {resource-directory-location}?if={value} 596 Accept Option: TBD3 598 Response 600 When successful, same response kind as in Section 4.2.1. 602 Example 604 => 0.01 GET 605 Uri-Path: path 606 Uri-Path: to 607 Uri-Path: resource 608 Uri-Path: directory 609 Uri-Query: if=sensor 610 Accept: TBD3 612 <= 2.05 Content 613 Content-Format: TBD3 615 #using 616 #using iana = 618 rd-item { 619 rt "temperature-c" 620 if "sensor" 621 iana:describedby 622 iana:alternate 623 } 624 rd-item { 625 rt "light-lux" 626 if "sensor" 627 } 629 5.2.4. List Resource Registrations 631 Request 633 Request Method: GET 635 URI Template: {resource-directory-location} 637 Accept Option: TBD3 639 Response 641 When successful, the server returns a 2.05 (Content) response with 642 a representation in content format TBD3. The representation 643 contains or zero or more links with the link 644 relation type, each of which has a resource registration as the 645 link target. 647 Example 649 => 0.01 GET 650 Uri-Path: path 651 Uri-Path: to 652 Uri-Path: resource 653 Uri-Path: directory 654 Accept: TBD3 656 <= 2.05 Content 657 Content-Format: TBD3 659 #using 661 rd-unit 662 rd-unit 663 rd-unit 664 rd-unit 666 5.2.5. Create Resource Registration 668 Request 670 Request Method: POST 672 URI Template: {resource-directory-location} 674 Content-Format Option: TBD3 676 The client submits a representation in content format TBD3. The 677 representation contains zero or more links with the link relation type, each of which has a resource to be 679 registered as the link target. 681 Response 683 When successful, the server returns a 2.01 (Created) response 684 indicating the location at which the resource registration was 685 created. 687 Example 689 => 0.02 POST 690 Uri-Path: path 691 Uri-Path: to 692 Uri-Path: resource 693 Uri-Path: directory 694 Content-Format: TBD3 696 #base 697 rd-item { rt "light" ct 0 } 698 rd-item { rt "light" ct 0 } 699 rd-item { rt "light" ct 0 } 701 <= 2.01 Created 702 Location-Path: path 703 Location-Path: to 704 Location-Path: resource 705 Location-Path: directory 706 Location-Path: 42 708 5.2.6. Read Resource Registration 710 Request 712 Request Method: GET 714 URI Template: {registration-location} 716 Accept Option: TBD3 718 Response 720 When successful, same response kind as in Section 4.2.1. 722 Example 724 => 0.01 GET 725 Uri-Path: path 726 Uri-Path: to 727 Uri-Path: resource 728 Uri-Path: directory 729 Uri-Path: 42 730 Accept: TBD3 732 <= 2.05 Content 733 Content-Format: TBD3 735 #base 736 rd-item { rt "light" ct 0 } 737 rd-item { rt "light" ct 0 } 738 rd-item { rt "light" ct 0 } 740 5.2.7. Update Resource Registration 742 Request 744 Request Method: PUT 746 URI Template: {registration-location} 748 Content-Format Option: TBD3 750 The client submits a representation in content format TBD3. The 751 representation contains zero or more links with the link relation type, each of which has a resource to be 753 registered as the link target. Any existing list of resources at 754 the location is replaced by this update. 756 Response 758 When successful, the server returns a 2.04 (Changed) response. 760 Example 762 => 0.03 PUT 763 Uri-Path: path 764 Uri-Path: to 765 Uri-Path: resource 766 Uri-Path: directory 767 Uri-Path: 42 768 Content-Format: TBD3 770 #base 771 rd-item { rt "light" ct 0 } 772 rd-item { rt "light" ct 0 } 774 <= 2.04 Changed 776 5.2.8. Delete Resource Registration 778 Request 780 Request Method: DELETE 782 URI Template: {registration-location} 784 Response 786 When successful, the server returns a 2.02 (Deleted) response. 788 Example 790 => 0.04 DELETE 791 Uri-Path: path 792 Uri-Path: to 793 Uri-Path: resource 794 Uri-Path: directory 795 Uri-Path: 42 797 <= 2.02 Deleted 799 6. Security Considerations 801 TODO. 803 7. IANA Considerations 805 7.1. CoRE Dictionary 807 This document creates a new registry named "CoRAL Dictionary for 808 CoRE" under the Constrained RESTful Environments (CoRE) Parameters" 809 registry [CORE-PARAMETERS] for use with the CoRAL binary format 810 [I-D.hartke-t2trg-coral]. The registry is located at . 812 The registry is a mapping between a key and a value. The key is an 813 integer in the range 0 to 2147483647 (2^31-1). The value is either 814 an Internationalized Resource Identifier (IRI) reference, a Boolean 815 value, an integer, a floating-point number, a date/time value, a byte 816 string, or a text string. Both the key and the value are to be 817 denoted in the CoRAL textual format [I-D.hartke-t2trg-coral] and must 818 be unique within the registry. A reference may be provided to offer 819 more information about a value. 821 The registry policy is Expert Review. 823 The initial entries in the registry are as follows: 825 o Key: 0 826 Value: 827 Reference: [W3C.REC-rdf-schema-20140225] 829 o Key: 1 830 Value: 831 Reference: [RFC6573] 833 o Key: 2 834 Value: 835 Reference: [RFC6573] 837 o Key: 3 838 Value: 839 Reference: [I-D.hartke-t2trg-coral] 841 o Key: 4 842 Value: 843 Reference: [I-D.hartke-t2trg-coral] 845 o Key: 5 846 Value: 847 Reference: [I-D.hartke-t2trg-coral] 849 o Key: 6 850 Value: 851 Reference: [I-D.hartke-t2trg-coral] 853 o Key: 7 854 Value: 855 Reference: [I-D.hartke-t2trg-coral] 857 o Key: 8 858 Value: 859 Reference: [I-D.hartke-t2trg-coral-reef] 861 o Key: 9 862 Value: 863 Reference: [I-D.hartke-t2trg-coral-reef] 865 o Key: 10 866 Value: 867 Reference: [I-D.hartke-t2trg-coral-reef] 869 o Key: 11 870 Value: 871 Reference: [I-D.hartke-t2trg-coral-reef] 873 o Key: 12 874 Value: 875 Reference: [I-D.hartke-t2trg-coral-reef] 877 o Key: 13 878 Value: 879 Reference: [I-D.hartke-t2trg-coral-reef] 881 o Key: 14 882 Value: 883 Reference: [I-D.hartke-t2trg-coral-reef] 885 o Key: 15 886 Value: 887 Reference: [I-D.hartke-t2trg-coral-reef] 889 o Key: 16 890 Value: 891 Reference: [I-D.hartke-t2trg-coral-reef] 893 o Key: 17 894 Value: 895 Reference: [I-D.hartke-t2trg-coral-reef] 897 o Key: 18 898 Value: 899 Reference: [I-D.hartke-t2trg-coral-reef] 901 7.2. CoAP Content Format 903 This document registers a CoAP content format for CoRAL documents in 904 the binary format that use the registry established in Section 7.1. 905 The registration is in accordance with the procedures of RFC 7252 906 [RFC7252]. 908 o Content Type: application/coral+cbor; dictionary=http://TBD5/ 909 Content Coding: identity 910 ID: TBD3 911 Reference: [I-D.hartke-t2trg-coral-reef] [I-D.hartke-t2trg-coral] 913 8. References 915 8.1. Normative References 917 [I-D.hartke-t2trg-coral] 918 Hartke, K., "The Constrained RESTful Application Language 919 (CoRAL)", draft-hartke-t2trg-coral-08 (work in progress), 920 March 2019. 922 [I-D.nottingham-rfc5785bis] 923 Nottingham, M., "Well-Known Uniform Resource Identifiers 924 (URIs)", draft-nottingham-rfc5785bis-09 (work in 925 progress), February 2019. 927 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 928 Requirement Levels", BCP 14, RFC 2119, 929 DOI 10.17487/RFC2119, March 1997, 930 . 932 [RFC6573] Amundsen, M., "The Item and Collection Link Relations", 933 RFC 6573, DOI 10.17487/RFC6573, April 2012, 934 . 936 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 937 Application Protocol (CoAP)", RFC 7252, 938 DOI 10.17487/RFC7252, June 2014, 939 . 941 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 942 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 943 May 2017, . 945 [W3C.REC-rdf-schema-20140225] 946 Brickley, D. and R. Guha, "RDF Schema 1.1", World Wide Web 947 Consortium Recommendation REC-rdf-schema-20140225, 948 February 2014, 949 . 951 8.2. Informative References 953 [CORE-PARAMETERS] 954 IANA, "Constrained RESTful Environments (CoRE) 955 Parameters", 956 . 958 [I-D.ietf-core-resource-directory] 959 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 960 Amsuess, "CoRE Resource Directory", draft-ietf-core- 961 resource-directory-19 (work in progress), January 2019. 963 [REST] Fielding, R., "Architectural Styles and the Design of 964 Network-based Software Architectures", Ph.D. Dissertation, 965 University of California, Irvine, 2000, 966 . 969 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 970 Resource Identifier (URI): Generic Syntax", STD 66, 971 RFC 3986, DOI 10.17487/RFC3986, January 2005, 972 . 974 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 975 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 976 . 978 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 979 Constrained-Node Networks", RFC 7228, 980 DOI 10.17487/RFC7228, May 2014, 981 . 983 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 984 DOI 10.17487/RFC8288, October 2017, 985 . 987 Acknowledgements 989 Thanks to Christian Amsuess and Carsten Bormann for helpful comments 990 and discussions that have shaped the document. 992 Author's Address 994 Klaus Hartke 995 Ericsson 996 Torshamnsgatan 23 997 Stockholm SE-16483 998 Sweden 1000 Email: klaus.hartke@ericsson.com