idnits 2.17.1 draft-hartke-core-apps-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 22, 2018) is 1985 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5785 (ref. '4') (Obsoleted by RFC 8615) ** Obsolete normative reference: RFC 7320 (ref. '5') (Obsoleted by RFC 8820) -- Obsolete informational reference (is this intentional?): RFC 7540 (ref. '8') (Obsoleted by RFC 9113) -- Obsolete informational reference (is this intentional?): RFC 7230 (ref. '14') (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7231 (ref. '15') (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 4 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: Informational October 22, 2018 5 Expires: April 25, 2019 7 CoRE Applications 8 draft-hartke-core-apps-08 10 Abstract 12 The application programmable interfaces of RESTful, hypermedia-driven 13 Web applications consist of a number of reusable components such as 14 Internet media types and link relation types. This document proposes 15 "CoRE Applications", a convention for application designers to build 16 the interfaces of their applications in a structured way, so that 17 implementers can easily build interoperable clients and servers, and 18 other designers can reuse the components in their own applications. 20 Note to Readers 22 This Internet-Draft should be discussed on the Thing-to-Thing 23 Research Group (T2TRG) mailing list 24 . 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 25, 2019. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. CoRE Applications . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Communication Protocols . . . . . . . . . . . . . . . . . 4 63 2.1.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . 4 64 2.2. Representation Formats . . . . . . . . . . . . . . . . . 5 65 2.2.1. Internet Media Types . . . . . . . . . . . . . . . . 5 66 2.3. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 2.3.1. Link Relation Types . . . . . . . . . . . . . . . . . 8 68 2.3.2. Template Variable Names . . . . . . . . . . . . . . . 8 69 2.4. Forms . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 2.4.1. Form Relation Types . . . . . . . . . . . . . . . . . 9 71 2.4.2. Form Field Names . . . . . . . . . . . . . . . . . . 9 72 2.5. Well-Known Locations . . . . . . . . . . . . . . . . . . 10 73 3. CoRE Application Descriptions . . . . . . . . . . . . . . . . 10 74 3.1. Template . . . . . . . . . . . . . . . . . . . . . . . . 11 75 4. URI Design Considerations . . . . . . . . . . . . . . . . . . 12 76 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 7.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 7.2. Informative References . . . . . . . . . . . . . . . . . 15 81 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 82 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 Representational State Transfer (REST) [16] is an architectural style 87 for distributed hypermedia systems. Over the years, REST has gained 88 popularity not only as an approach for large-scale information 89 dissemination, but also as the basic principle for designing and 90 building Internet-based applications in general. 92 In the coming years, the size and scope of the Internet is expected 93 to increase greatly as physical-world objects become smart enough to 94 communicate over the Internet -- a phenomenon known as the Internet 95 of Things (IoT). As things learn to speak the languages of the net, 96 the idea of applying REST principles to the design of IoT application 97 architectures suggests itself. To this end, the Constrained 98 Application Protocol (CoAP) [23] was created, an application-layer 99 protocol that enables RESTful applications in constrained-node 100 networks [10], giving rise to a new setting for Internet-based 101 applications: the Constrained RESTful Environment (CoRE). 103 To realize the full benefits and advantages of the REST architectural 104 style, a set of constraints needs to be maintained when designing 105 applications and their application programming interfaces (APIs). 106 One of the fundamental principles of REST is that "REST APIs must be 107 hypertext-driven" [17]. However, this principle is often ignored by 108 application designers. Instead, APIs are specified out-of-band in 109 terms of fixed URI patterns (e.g., in the API documentation or in a 110 machine-readable format that facilitates code generation). Although 111 this approach may appear easy for clients to use, the fixed resource 112 names and data formats lead to a tight coupling between client and 113 server implementations and make the system less flexible [5]. 114 Violations of REST design principles like this result in APIs that 115 may not be as scalable, extensible, and interoperable as promised by 116 REST. 118 REST is intended for network-based applications that are long-lived 119 and span multiple organizations [17]. Principled REST APIs require 120 some design effort, since application designers do not only have to 121 take current requirements into consideration, but also have to 122 anticipate changes that may be required in the future -- years or 123 even decades after the application has been deployed for the first 124 time. The reward is long-term stability and evolvability, both of 125 which are very desirable features in the Internet of Things. 127 To aid application designers in the design process, this document 128 proposes "CoRE Applications", a convention for building the APIs of 129 RESTful, hypermedia-driven Web applications. The goal is to help 130 application designers avoid common mistakes by focusing almost all of 131 the descriptive effort on defining the Internet media type(s) that 132 are used for representing resources and driving application state. 134 A template for a "CoRE Application Description" provides a consistent 135 format for the description of APIs so that implementers can easily 136 build interoperable clients and servers, and other application 137 designers can reuse the components in their own applications. 139 2. CoRE Applications 141 A CoRE Application API is a named set of reusable components. It 142 describes a contract between a server hosting an instance of the 143 described application and clients that wish to interface with that 144 instance. 146 The API is generally comprised of: 148 o communication protocols, identified by URI schemes, 150 o representation formats, identified by Internet media types, 152 o link relation types, 154 o form relation types, 156 o template variables in templated links, 158 o form field names in forms, and 160 o well-known locations. 162 Together, these components provide the specific, in-band instructions 163 to a client for interfacing with a given application. 165 2.1. Communication Protocols 167 The foundation of a hypermedia-driven REST API are the communication 168 protocol(s) spoken between a client and a server. Although HTTP/1.1 169 [14] is by far the most common communication protocol for REST APIs, 170 a REST API should typically not be dependent on any specific 171 communication protocol. 173 2.1.1. URI Schemes 175 The usage of a particular protocol by a client is guided by URI 176 schemes [7]. URI schemes specify the syntax and semantics of URI 177 references [1] that the server includes in hypermedia controls such 178 as links and forms. 180 A URI scheme refers to a family of protocols, typically distinguished 181 by a version number. For example, the "http" URI scheme refers to 182 the two members of the HTTP family of protocols: HTTP/1.1 [14] and 183 HTTP/2 [8] (as well as some predecessors). The specific HTTP version 184 used is negotiated between a client and a server in-band using the 185 version indicator in the HTTP request-line or the TLS Application- 186 Layer Protocol Negotiation (ALPN) extension [18]. 188 IANA maintains a list of registered URI schemes at 189 . 191 2.2. Representation Formats 193 In RESTful applications, clients and servers exchange representations 194 that capture the current or intended state of a resource and that are 195 labeled with a media type. A representation is a sequence of bytes 196 whose structure and semantics are specified by a representation 197 format: a set of rules for encoding information. 199 Representation formats should generally allow clients with different 200 goals, so they can do different things with the same data. The 201 specification of a representation format "describes a problem space, 202 not a prescribed relationship between client and server. Client and 203 server must share an understanding of the representations they're 204 passing back and forth, but they don't need to have the same idea of 205 what the problem is that needs to be solved." [21] 207 Representation formats and their specifications frequently evolve 208 over time. It is part of the responsibility of the designer of a new 209 version to insure both forward and backward compatibility: new 210 representations should work reasonably (with some fallback) with old 211 processors and old representations should work reasonably with new 212 processors [20]. 214 Representation formats enable hypermedia-driven applications when 215 they support the expression of hypermedia controls such as links 216 (Section 2.3) and forms (Section 2.4). 218 2.2.1. Internet Media Types 220 One of the most important aspect of hypermedia-driven communications 221 is the concept of Internet media types [2]. Media types are used to 222 label representations so that it is known how the representation 223 should be interpreted and how it is encoded. The centerpiece of a 224 CoRE Application Description should be one or more media types. 226 Note: The terms media type and representation format are often used 227 interchangeably. In this document, the term "media type" refers 228 specifically to a string of characters such as "application/xml" 229 that is used to label representations; the term "representation 230 format" refers to the definition of the syntax and semantics of 231 representations, such as XML 1.0 [12] or XML 1.1 [13]. 233 A media type identifies a versioned series of representation formats 234 (Section 2.2): a media type does not identify a particular version of 235 a representation format; rather, the media type identifies the 236 family, and includes provisions for version indicator(s) embedded in 237 the representations themselves to determine more precisely the nature 238 of how the data is to be interpreted [20]. A new media type is only 239 needed to designate a completely incompatible format [20]. 241 Media types consist of a top-level type and a subtype, structured 242 into trees [2]. Optionally, media types can have parameters. For 243 example, the media type "text/plain; charset=utf-8" is a subtype for 244 plain text under the "text" top-level type in the standards tree and 245 has a parameter "charset" with the value "utf-8". 247 Media types can be further refined by 249 o structured type name suffixes (e.g., "+xml" appended to the base 250 subtype name; see Section 4.2.8 of RFC 6838 [2]), 252 o a "profile" parameter (see Section 3.1 of RFC 6906 [24]), 254 o subtype information embedded in the representations themselves 255 (e.g., "xmlns" declarations in XML documents [11]), 257 or a similar annotation. An annotation directly in the media type is 258 generally preferable, since subtype information embedded in 259 representations can typically not be negotiated during content 260 negotiation (e.g., using the CoAP Accept option). 262 In CoAP, media types are paired with a content coding [15] to 263 indicate the "content format" [23] of a representation. Each content 264 format is assigned a numeric identifier that can be used instead of 265 the (more verbose) textual name of the media type in representation 266 formats with size constraints. The flat number space loses the 267 structural information that the textual names have, however. 269 The media type of a representation must be determined from in-band 270 information (e.g., from the CoAP Content-Format option). Clients 271 must not assume a structure from the application context or other 272 out-of-band information. 274 IANA maintains a list of registered Internet media types at 275 . 277 IANA maintains a list of registered structured suffixes at 278 . 280 IANA maintains a list of registered CoAP content formats at 281 . 283 2.3. Links 285 As defined in RFC 8288 [6], a link is a typed connection between two 286 resources. Additionally, a link is the primary means for a client to 287 navigate from one resource to another. 289 A link is comprised of: 291 o a link context, 293 o a link relation type that identifies the semantics of the link 294 (see Section 2.3.1), 296 o a link target, identified by a URI, and 298 o optionally, target attributes that further describe the link or 299 the link target. 301 A link can be viewed as a statement of the form "{link context} has a 302 {link relation type} resource at {link target}, which has {target 303 attributes}" [6]. For example, the resource 304 could have a "terms-of-service" resource at , 305 which has a representation with the media type "text/html". 307 There are two special kinds of links: 309 o An embedding link is a link with an additional hint: when the link 310 is processed, it should be substituted with the representation of 311 the referenced resource rather than cause the client to navigate 312 away from the current resource. Thus, traversing an embedding 313 link adds to the current state rather than replacing it. 315 The most well known example for an embedding link is the HTML 316 element. When a Web browser processes this element, it 317 automatically dereferences the "src" and renders the resulting 318 image in place of the element. 320 o A templated link is a link where the client constructs the link 321 target URI from provided in-band instructions. The specific rules 322 for such instructions are described by the representation format. 323 URI Templates [3] provide a generic way to construct URIs through 324 variable expansion. 326 Templated links allow a client to construct resource URIs without 327 being coupled to the resource structure at the server, provided 328 that the client learns the template from a representation sent by 329 the server and does not have the template hard-coded. 331 2.3.1. Link Relation Types 333 A link relation type identifies the semantics of a link [6]. For 334 example, a link with the relation type "copyright" indicates that the 335 resource identified by the target URI is a statement of the copyright 336 terms applying to the link context. 338 Relation types are not to be confused with media types; they do not 339 identify the format of the representation that results when the link 340 is dereferenced [6]. Rather, they only describe how the link context 341 is related to another resource [6]. 343 IANA maintains a list of registered link relation types at 344 . 346 Applications that don't wish to register a link relation type can use 347 an extension link relation type [6]: a URI that uniquely identifies 348 the link relation type. For example, an application can use the 349 string "http://example.com/foo" as link relation type without having 350 to register it. Using a URI to identify an extension link relation 351 type, rather than a simple string, reduces the probability of 352 different link relation types using the same identifiers. 354 2.3.2. Template Variable Names 356 A templated link enables clients to construct the target URI of a 357 link, for example, when the link refers to a space of resources 358 rather than a single resource. The most prominent mechanisms for 359 this are URI Templates [3] and the HTML
element with a 360 submission method of GET. 362 To enable an automated client to construct an URI reference from a 363 URI Template, the name of the variable in the template can be used to 364 identify the semantics of the variable. For example, when retrieving 365 the representation of a collection of temperature readings, a 366 variable named "threshold" could indicate the variable for setting a 367 threshold of the readings to retrieve. 369 Template variable names are scoped to link relation types, i.e., two 370 variables with the same name can have different semantics if they 371 appear in links with different link relation types. 373 2.4. Forms 375 A form is the primary means for a client to submit information to a 376 server, typically in order to change resource state. 378 A form is comprised of: 380 o a form context, 382 o a form relation type that identifies the semantics of the form 383 (see Section 2.4.1), 385 o a request method (e.g., PUT, POST, DELETE), 387 o a submission URI, 389 o a description of a representation that the server expects as part 390 of the form submission, and 392 o optionally, target attributes that further describe the form or 393 the form target. 395 A form can be viewed as an instruction of the form "To perform a 396 {form relation type} operation on {form context}, make a {request 397 method} request to {submission URI}, which has {target attributes}". 398 For example, to "update" the resource , a 399 client would make a PUT request to . (In 400 many cases, the target of a form is the same resource as the context, 401 but this is not required.) 403 The description of the expected representation can be a set of form 404 fields (see Section 2.4.2) or simply a list of acceptable media 405 types. 407 Note: A form with a submission method of GET is, strictly speaking, 408 a templated link, since it provides a way to construct a URI and 409 does not submit a representation to the server. 411 2.4.1. Form Relation Types 413 A form relation type identifies the semantics of a form. For 414 example, a form with the form relation type "create" indicates that a 415 new item can be created within the form context by making a request 416 to the resource identified by the target URI. 418 Similarly to extension link relation types, applications can use 419 extension form relation types when they don't wish to register a form 420 relation type. 422 2.4.2. Form Field Names 424 Forms can have a detailed description of the representation expected 425 by the server as part of form submission. This description typically 426 consists of a set of form fields where each form field is comprised 427 of a field name, a field type, and optionally a number of attributes 428 such as a default value, a validation rule or a human-readable label. 430 To enable an automated client to fill out a form, the field name can 431 be used to identify the semantics of the form field. For example, 432 when controlling a smart light bulb, the field name "brightness" 433 could indicate the field for setting the desired brightness of the 434 light bulb. 436 Field names are scoped to form relation types, i.e., two form fields 437 with the same name can have different semantics if they appear in 438 forms with different form relation types. 440 The type of a form field is a data type such as "an integer between 1 441 and 100" or "an RGB color". The type is orthogonal to the field 442 name, i.e., the type should not be determined from the field name 443 even though the client can identify the semantics of the field from 444 the name. This separation makes it easy to change the set of 445 acceptable values in the future. 447 2.5. Well-Known Locations 449 Some applications may require the discovery of information about a 450 host, known as "site-wide metadata" in RFC 5785 [4]. For example, 451 RFC 6415 [19] defines a metadata document format for describing a 452 host; similarly, RFC 6690 [22] defines a link format for the 453 discovery of resources hosted by a server. 455 Applications that need to define a resource for this kind of metadata 456 can register new "well-known locations". RFC 5785 [4] defines the 457 path prefix "/.well-known/" in "http" and "https" URIs for this 458 purpose. RFC 7252 [23] extends this convention to "coap" and "coaps" 459 URIs. 461 IANA maintains a list of registered well-known URIs at 462 . 464 3. CoRE Application Descriptions 466 As applications are implemented and deployed, it becomes important to 467 describe them in some structured way. This section provides a simple 468 template for CoRE Application Descriptions. A uniform structure 469 allows implementers to easily determine the components that make up 470 the interface of an application. 472 The template below lists all components of applications that both the 473 client and the server implementation of the application need to 474 understand in order to interoperate. Crucially, items not listed in 475 the template are not part of the contract between clients and servers 476 -- they are implementation details. This includes in particular the 477 URIs of resources (see Section 4). 479 CoRE Application Descriptions are intended to be published in human- 480 readable format by designers of applications and by operators of 481 deployed application instances. Application designers may publish an 482 application description as a general specification of all application 483 instances, so that implementers can create interoperable clients and 484 servers. Operators of application instances may publish an 485 application description as part of the API documentation of the 486 service, which should also include instructions how the service can 487 be located and which communication protocols and security modes are 488 used. 490 3.1. Template 492 The fields of the template are as follows: 494 Application name: 495 Name of the application. The name is not used to negotiate 496 capabilities; it is purely informational. A name may include a 497 version number or, for example, refer to a living standard that is 498 updated continuously. 500 URI schemes: 501 URI schemes identifying the communication protocols that need to 502 be understood by clients and servers. This information is mostly 503 relevant for deployed instances of the application rather than for 504 the general specification of the application. 506 Media types: 507 Internet media types that identify the representation formats that 508 need to be understood by clients and servers. An application 509 description must comprise at least one media type. Additional 510 media types may be required or optional. 512 Link relation types: 513 Link relation types that identify the semantics of links. An 514 application description may comprise IANA-registered link relation 515 types and extension link relation types. Both may be required or 516 optional. 518 Template variable names: 519 For each link relation type, variable names that identify the 520 semantics of variables in templated links with that link relation 521 type. Whether a template variable is required or optional is 522 indicated in-band inside the templated link. 524 Form relation types: 525 Form relation types that identify the semantics of forms and, for 526 each form relation type, the submission method(s) to be used. An 527 application description may comprise IANA-registered form relation 528 types and extension form relation types. Both may be required or 529 optional. 531 Form field names: 532 For each form relation type, form field names that identify the 533 semantics of form fields in forms with that form relation type. 534 Whether a form field is required or optional is indicated in-band 535 inside the form. 537 Well-known locations: 538 Well-known locations in the resource identifier space of servers 539 that clients can use to discover information given the DNS name or 540 IP address of a server. 542 Interoperability considerations: 543 Any issues regarding the interoperable use of the components of 544 the application should be given here. 546 Security considerations: 547 Security considerations for the security of the application must 548 be specified here. 550 Contact: 551 Person (including contact information) to contact for further 552 information. 554 Author/Change controller: 555 Person (including contact information) authorized to change this 556 application description. 558 Each field should include full citations for all specifications 559 necessary to understand the application components. 561 4. URI Design Considerations 563 URIs [1] are a cornerstone of RESTful applications. They enable 564 uniform identification of resources via URI schemes [7] and are used 565 every time a client interacts with a particular resource or when a 566 resource representation references another resource. 568 URIs often include structured application data in the path and query 569 components, such as paths in a filesystem or keys in a database. It 570 is common for many RESTful applications to use these structures not 571 only as an implementation detail but also make them part of the 572 public REST API, prescribing a fixed format for this data. However, 573 there are a number of problems with this practice [5], in particular 574 if the application designer and the server owner are not the same 575 entity. 577 In hypermedia-driven applications, URIs are therefore not included in 578 the application interface. A CoRE Application Description must not 579 mandate any particular form of URI substructure. 581 RFC 7320 [5] describes the problematic practice of fixed URI 582 structures in detail and provides some acceptable alternatives. 584 Nevertheless, the design of the URI structure on a server is an 585 essential part of implementing a RESTful application, even though it 586 is not part of the application interface. The server implementer is 587 responsible for binding the resources identified by the application 588 designer to URIs. 590 A good RESTful URI is: 592 o Short. Short URIs are easier to remember and cause less overhead 593 in requests and representations. 595 o Meaningful. A URI should describe the resource in a way that is 596 meaningful and useful to humans. 598 o Consistent. URIs should follow a consistent pattern to make it 599 easy to reason about the application. 601 o Bookmarkable. Cool URIs don't change [9]. However, in practice, 602 application resource structures do change. That should cause URIs 603 to change as well so they better reflect reality. Implementations 604 should not depend on unchanging URIs. 606 o Shareable. A URI should not be context sensitive, e.g., to the 607 currently logged-in user. It should be possible to share a URI 608 with third parties so they can access the same resource. 610 o Extension-less. Some applications return different data for 611 different extensions, e.g., for "contacts.xml" or "contacts.json". 612 But different URIs imply different resources. RESTful URIs should 613 identify a single resource. Different representations of the 614 resource can be negotiated (e.g., using the CoAP Accept option). 616 5. Security Considerations 618 The security considerations of RFC 3986 [1], RFC 5785 [4], RFC 6570 619 [3], RFC 6838 [2], RFC 7320 [5], RFC 7595 [7], and RFC 8288 [6] are 620 inherited. 622 All components of an application description are expected to contain 623 clear security considerations. CoRE Application Descriptions should 624 furthermore contain security considerations that need to be taken 625 into account for the security of the overall application. 627 6. IANA Considerations 629 This document has no IANA actions. 631 7. References 633 7.1. Normative References 635 [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 636 Resource Identifier (URI): Generic Syntax", STD 66, 637 RFC 3986, DOI 10.17487/RFC3986, January 2005, 638 . 640 [2] Freed, N., Klensin, J., and T. Hansen, "Media Type 641 Specifications and Registration Procedures", BCP 13, 642 RFC 6838, DOI 10.17487/RFC6838, January 2013, 643 . 645 [3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 646 and D. Orchard, "URI Template", RFC 6570, 647 DOI 10.17487/RFC6570, March 2012, 648 . 650 [4] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known 651 Uniform Resource Identifiers (URIs)", RFC 5785, 652 DOI 10.17487/RFC5785, April 2010, 653 . 655 [5] Nottingham, M., "URI Design and Ownership", BCP 190, 656 RFC 7320, DOI 10.17487/RFC7320, July 2014, 657 . 659 [6] Nottingham, M., "Web Linking", RFC 8288, 660 DOI 10.17487/RFC8288, October 2017, 661 . 663 [7] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 664 and Registration Procedures for URI Schemes", BCP 35, 665 RFC 7595, DOI 10.17487/RFC7595, June 2015, 666 . 668 7.2. Informative References 670 [8] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 671 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 672 DOI 10.17487/RFC7540, May 2015, 673 . 675 [9] Berners-Lee, T., "Cool URIs don't change", 1998, 676 . 678 [10] Bormann, C., Ersue, M., and A. Keranen, "Terminology for 679 Constrained-Node Networks", RFC 7228, 680 DOI 10.17487/RFC7228, May 2014, 681 . 683 [11] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 684 Thompson, "Namespaces in XML 1.0 (Third Edition)", World 685 Wide Web Consortium Recommendation REC-xml-names-20091208, 686 December 2009, 687 . 689 [12] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 690 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 691 Edition)", World Wide Web Consortium Recommendation REC- 692 xml-20081126, November 2008, 693 . 695 [13] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., 696 Yergeau, F., and J. Cowan, "Extensible Markup Language 697 (XML) 1.1 (Second Edition)", World Wide Web Consortium 698 Recommendation REC-xml11-20060816, August 2006, 699 . 701 [14] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 702 Protocol (HTTP/1.1): Message Syntax and Routing", 703 RFC 7230, DOI 10.17487/RFC7230, June 2014, 704 . 706 [15] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 707 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 708 DOI 10.17487/RFC7231, June 2014, 709 . 711 [16] Fielding, R., "Architectural Styles and the Design of 712 Network-based Software Architectures", Ph.D. Dissertation, 713 University of California, Irvine, 2000, 714 . 717 [17] Fielding, R., "REST APIs must be hypertext-driven", 718 October 2008, . 721 [18] Friedl, S., Popov, A., Langley, A., and E. Stephan, 722 "Transport Layer Security (TLS) Application-Layer Protocol 723 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 724 July 2014, . 726 [19] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", 727 RFC 6415, DOI 10.17487/RFC6415, October 2011, 728 . 730 [20] Masinter, L., "MIME and the Web", draft-masinter-mime-web- 731 info-02 (work in progress), January 2011. 733 [21] Richardson, L. and M. Amundsen, "RESTful Web APIs", 734 O'Reilly Media, ISBN 978-1-4493-5806-8, September 2013. 736 [22] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 737 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 738 . 740 [23] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 741 Application Protocol (CoAP)", RFC 7252, 742 DOI 10.17487/RFC7252, June 2014, 743 . 745 [24] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, 746 DOI 10.17487/RFC6906, March 2013, 747 . 749 Acknowledgements 751 Jan Algermissen, Mike Amundsen, Mike Kelly, Julian Reschke, and Erik 752 Wilde provided valuable input on link and form relation types. 754 Thanks to Olaf Bergmann, Carsten Bormann, Stefanie Gerdes, Ari 755 Keranen, Michael Koster, Matthias Kovatsch, Teemu Savolainen, and 756 Bilhanan Silverajan for helpful comments and discussions that have 757 shaped the document. 759 Some of the text in this document has been borrowed from [5], [6], 760 [17], and [20]. All errors are my own. 762 This work was funded in part by Nokia. 764 Author's Address 766 Klaus Hartke 767 Ericsson 768 Torshamnsgatan 23 769 Stockholm SE-16483 770 Sweden 772 Email: klaus.hartke@ericsson.com