idnits 2.17.1 draft-hartke-t2trg-coral-reef-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2019) is 1747 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 915, but not defined == Outdated reference: A later version (-28) exists of draft-ietf-core-resource-directory-22 Summary: 0 errors (**), 0 flaws (~~), 3 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 July 8, 2019 5 Expires: January 9, 2020 7 Resource Discovery in Constrained RESTful Environments (CoRE) 8 using the Constrained RESTful Application Language (CoRAL) 9 draft-hartke-t2trg-coral-reef-02 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 January 9, 2020. 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 . . . . . . . . . . . . . . . . . 7 59 3. Resource Metadata . . . . . . . . . . . . . . . . . . . . . . 7 60 4. Resource Discovery . . . . . . . . . . . . . . . . . . . . . 8 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 160 contain nested elements with resource metadata (such as resource 161 type, interface description, available content formats, and related 162 resources). 164 => 0.01 GET 165 Uri-Path: .well-known 166 Uri-Path: core 167 Accept: TBD3 169 <= 2.05 Content 170 Content-Format: TBD3 172 #using 173 #using iana = 175 rd-item { 176 ct 40 177 title "Sensor Index" 178 } 179 rd-item { 180 rt "temperature-c" 181 if "sensor" 182 iana:describedby 183 iana:alternate 184 } 185 rd-item { 186 rt "light-lux" 187 if "sensor" 188 } 190 In detail, this representation contains links to three resources of 191 interest on the server: , , and . 194 For , a content format hint ("ct") and a title ("title") 195 are provided as resource metadata. For as well as 196 , a resource type ("rt") and an interface description 197 ("if") are provided as resource metadata. Additionally, two links 198 are provided with further detail on : one to a schema 199 describing this resource ("describedby") and one to an substitute for 200 this resource ("alternate"). 202 2.2. Resource Directory 204 In many deployment scenarios, such as in constrained networks with 205 sleeping servers or in large M2M deployments with bandwidth limited 206 access networks, it is beneficial to deploy resource directory 207 entities that store links to resources stored on other servers. A 208 resource directory can be thought of as a limited search engine for 209 M2M resources. 211 In this specification, a resource directory provides the same lookup 212 interface as a "/.well-known/core" resource, except that it provides 213 links to resources on potentially many different servers. For 214 populating the resource directory, a registration interface is 215 offered. The registration interface is a collection resource with 216 the common operations of create, read, update, and delete. The items 217 of the collection are groups of links of type that are to be made available in the lookup interface. 220 The following example shows how a client registers a group of links 221 with a CoAP resource directory by making a POST request to the 222 collection resource. The client receives a 2.01 (Created) response 223 with the location of the created collection item. The client can use 224 this location later to update the group of links or delete them from 225 the directory. 227 => 0.02 POST 228 Uri-Path: path 229 Uri-Path: to 230 Uri-Path: resource 231 Uri-Path: directory 232 Content-Format: TBD3 234 #using 236 #base 237 rd-item { rt "light-lux" ct 0 } 238 rd-item { rt "light-lux" ct 0 } 239 rd-item { rt "light-lux" ct 0 } 241 <= 2.01 Created 242 Location-Path: path 243 Location-Path: to 244 Location-Path: resource 245 Location-Path: directory 246 Location-Path: 42 248 The following example shows how a client performs a lookup on the 249 resource directory by making a GET request to the resource directory 250 resource. The client receives a 2.05 (Content) response with a 251 combined view of all groups of links registered earlier, filtered by 252 a query. 254 => 0.01 GET 255 Uri-Path: path 256 Uri-Path: to 257 Uri-Path: resource 258 Uri-Path: directory 259 Uri-Query: rt=light-lux 260 Accept: TBD3 262 <= 2.05 Content 263 Content-Format: TBD3 265 #using 267 #base 268 rd-item { rt "light-lux" } 270 #base 271 rd-item { rt "light-lux" ct 0 } 272 rd-item { rt "light-lux" ct 0 } 273 rd-item { rt "light-lux" ct 0 } 275 2.3. Notational Conventions 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 279 "OPTIONAL" in this document are to be interpreted as described in BCP 280 14 [RFC2119] [RFC8174] when, and only when, they appear in all 281 capitals, as shown here. 283 3. Resource Metadata 285 Both "/.well-known/core" resources and resource directories link to 286 resources of interest using the 287 link relation type. Metadata for these resources can be expressed by 288 nesting further links inside these links. 290 The following link relation types for resource metadata are defined: 292 293 The link target is a hint indicating what the (human-spoken) 294 language of the result of dereferencing the link context should 295 be. 297 298 The link target indicates the intended destination medium or media 299 for style information for the link context. 301 302 The link target is a label that it can be used as a human-readable 303 identifier for the link context. 305 The link can have a nested link containing language information. 307 308 The link target is a hint indicating what the media type of the 309 result of dereferencing the link context should be. 311 312 The link target is an application-specific semantic type of the 313 link context. 315 Multiple resource types can be specified, each as a link with the 316 resource type as link target. The link target MUST NOT contain 317 multiple resource types separated by white space. 319 320 The link target is a specific interface definition that can be 321 used to interact with the link context. 323 324 The link target is an indication of the maximum size of the 325 resource representation returned by performing a GET on the link 326 context. 328 329 The link target is a hint about the Content-Formats that the link 330 context returns. 332 4. Resource Discovery 334 Given a host name or IP address, a client can discover the resources 335 of a server implementing this section through the use of a well-known 336 resource [RFC8615]. Well-known resources have a path component that 337 begins with "/.well-known/". This specification defines a new well- 338 known resource for CoRE Resource Discovery: "/.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. The representation MUST 373 contain zero or more links of type , each of which MUST target a resource in the namespace of 375 the server (same origin). The links may have nested elements 376 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 relation type, each of which has a resource 645 registration as the 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 678 link relation type, each of 679 which has a resource to be 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 752 link relation type, each of 753 which has a resource to be registered as the link target. Any 754 existing list of resources at the location is replaced by this 755 update. 757 Response 759 When successful, the server returns a 2.04 (Changed) response. 761 Example 763 => 0.03 PUT 764 Uri-Path: path 765 Uri-Path: to 766 Uri-Path: resource 767 Uri-Path: directory 768 Uri-Path: 42 769 Content-Format: TBD3 771 #base 772 rd-item { rt "light" ct 0 } 773 rd-item { rt "light" ct 0 } 775 <= 2.04 Changed 777 5.2.8. Delete Resource Registration 779 Request 781 Request Method: DELETE 783 URI Template: {registration-location} 785 Response 787 When successful, the server returns a 2.02 (Deleted) response. 789 Example 791 => 0.04 DELETE 792 Uri-Path: path 793 Uri-Path: to 794 Uri-Path: resource 795 Uri-Path: directory 796 Uri-Path: 42 798 <= 2.02 Deleted 800 6. Security Considerations 802 TODO. 804 7. IANA Considerations 806 7.1. CoRE Dictionary 808 This document creates a new registry named "CoRAL Dictionary for 809 CoRE" under the Constrained RESTful Environments (CoRE) Parameters" 810 registry [CORE-PARAMETERS] for use with the CoRAL binary format 811 [I-D.hartke-t2trg-coral]. The registry is located at . 813 [[NOTE TO RFC EDITOR: Please replace all occurrences of 814 "http://TBD5/" in this document with the URI of the new registry.]] 816 The registry is a mapping between a key and a value. The key is an 817 integer in the range 0 to 2147483647 (2^31-1). The value is either 818 an Internationalized Resource Identifier (IRI) reference, a Boolean 819 value, an integer, a floating-point number, a date/time value, a byte 820 string, or a text string. Both the key and the value are to be 821 denoted in the CoRAL textual format [I-D.hartke-t2trg-coral] and must 822 be unique within the registry. A reference may be provided to offer 823 more information about a value. 825 The registry policy is Expert Review. 827 The initial entries in the registry are as follows: 829 o Key: 0 830 Value: 831 Reference: [W3C.REC-rdf-schema-20140225] 833 o Key: 1 834 Value: 835 Reference: [RFC6573] 837 o Key: 2 838 Value: 839 Reference: [RFC6573] 841 o Key: 3 842 Value: 843 Reference: [I-D.hartke-t2trg-coral] 845 o Key: 4 846 Value: 847 Reference: [I-D.hartke-t2trg-coral] 849 o Key: 5 850 Value: 851 Reference: [I-D.hartke-t2trg-coral] 853 o Key: 6 854 Value: 855 Reference: [I-D.hartke-t2trg-coral] 857 o Key: 7 858 Value: 859 Reference: [I-D.hartke-t2trg-coral] 861 o Key: 8 862 Value: 863 Reference: [I-D.hartke-t2trg-coral-reef] 865 o Key: 9 866 Value: 867 Reference: [I-D.hartke-t2trg-coral-reef] 869 o Key: 10 870 Value: 871 Reference: [I-D.hartke-t2trg-coral] 873 o Key: 11 874 Value: 875 Reference: [I-D.hartke-t2trg-coral-reef] 877 o Key: 12 878 Value: 879 Reference: [I-D.hartke-t2trg-coral-reef] 881 o Key: 13 882 Value: 883 Reference: [I-D.hartke-t2trg-coral] 885 o Key: 14 886 Value: 887 Reference: [I-D.hartke-t2trg-coral-reef] 889 o Key: 15 890 Value: 891 Reference: [I-D.hartke-t2trg-coral-reef] 893 o Key: 16 894 Value: 895 Reference: [I-D.hartke-t2trg-coral-reef] 897 o Key: 17 898 Value: 899 Reference: [I-D.hartke-t2trg-coral-reef] 901 o Key: 18 902 Value: 903 Reference: [I-D.hartke-t2trg-coral-reef] 905 7.2. CoAP Content Format 907 This document registers a CoAP content format for CoRAL documents in 908 the binary format that use the registry established in Section 7.1. 909 The registration is in accordance with the procedures of RFC 7252 910 [RFC7252]. 912 o Content Type: application/coral+cbor;dictionary="http://TBD5/" 913 Content Coding: identity 914 ID: TBD3 915 Reference: [I-D.hartke-t2trg-coral-reef] 917 [[NOTE TO RFC EDITOR: Please replace all occurrences of "TBD3" in 918 this document with the code point assigned by IANA.]] 920 [[NOTE TO IMPLEMENTERS: Experimental implementations can use content 921 format ID 65088 until IANA has assigned a code point.]] 923 8. References 925 8.1. Normative References 927 [I-D.hartke-t2trg-coral] 928 Hartke, K., "The Constrained RESTful Application Language 929 (CoRAL)", draft-hartke-t2trg-coral-09 (work in progress), 930 July 2019. 932 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 933 Requirement Levels", BCP 14, RFC 2119, 934 DOI 10.17487/RFC2119, March 1997, 935 . 937 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 938 Application Protocol (CoAP)", RFC 7252, 939 DOI 10.17487/RFC7252, June 2014, 940 . 942 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 943 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 944 May 2017, . 946 [RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers 947 (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, 948 . 950 8.2. Informative References 952 [CORE-PARAMETERS] 953 IANA, "Constrained RESTful Environments (CoRE) 954 Parameters", 955 . 957 [I-D.ietf-core-resource-directory] 958 Shelby, Z., Koster, M., Bormann, C., Stok, P., and C. 959 Amsuess, "CoRE Resource Directory", draft-ietf-core- 960 resource-directory-22 (work in progress), July 2019. 962 [REST] Fielding, R., "Architectural Styles and the Design of 963 Network-based Software Architectures", Ph.D. Dissertation, 964 University of California, Irvine, 2000, 965 . 968 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 969 Resource Identifier (URI): Generic Syntax", STD 66, 970 RFC 3986, DOI 10.17487/RFC3986, January 2005, 971 . 973 [RFC6573] Amundsen, M., "The Item and Collection Link Relations", 974 RFC 6573, DOI 10.17487/RFC6573, April 2012, 975 . 977 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 978 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 979 . 981 [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 982 Constrained-Node Networks", RFC 7228, 983 DOI 10.17487/RFC7228, May 2014, 984 . 986 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 987 DOI 10.17487/RFC8288, October 2017, 988 . 990 [W3C.REC-rdf-schema-20140225] 991 Brickley, D. and R. Guha, "RDF Schema 1.1", World Wide Web 992 Consortium Recommendation REC-rdf-schema-20140225, 993 February 2014, 994 . 996 Acknowledgements 998 Thanks to Christian Amsuess and Carsten Bormann for helpful comments 999 and discussions that have shaped the document. 1001 Author's Address 1003 Klaus Hartke 1004 Ericsson 1005 Torshamnsgatan 23 1006 Stockholm SE-16483 1007 Sweden 1009 Email: klaus.hartke@ericsson.com