Thing-to-Thing Research Group K. Hartke Internet-Draft Universitaet Bremen TZI Intended status: Informational February 12, 2017 Expires: August 16, 2017 CoRE Application Descriptions draft-hartke-core-apps-07 Abstract The interfaces of RESTful, hypermedia-driven Web applications consist of reusable components such as Internet media types and link relation types. This document proposes CoRE Application Descriptions, a convention for application designers to describe the programmable interfaces of their applications in a structured way so that other parties can easily develop interoperable clients and servers or reuse the components in their own applications. Note to Readers This Internet-Draft should be discussed on the Thing-to-Thing Research Group (T2TRG) mailing list . Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 16, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. Hartke Expires August 16, 2017 [Page 1] Internet-Draft CoRE Application Descriptions February 2017 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Application Descriptions . . . . . . . . . . . . . . . . . . 4 2.1. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Internet Media Types . . . . . . . . . . . . . . . . . . 5 2.2.1. Representation Formats . . . . . . . . . . . . . . . 6 2.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2.3. Forms . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Link Relation Types . . . . . . . . . . . . . . . . . . . 8 2.3.1. Template Variable Names . . . . . . . . . . . . . . . 9 2.4. Form Relation Types . . . . . . . . . . . . . . . . . . . 9 2.4.1. Form Field Names . . . . . . . . . . . . . . . . . . 10 2.5. Well-Known Locations . . . . . . . . . . . . . . . . . . 10 3. Application Description Template . . . . . . . . . . . . . . 11 4. URI Design Considerations . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6.1. Content-Format Registry . . . . . . . . . . . . . . . . . 14 6.2. Link Relation Type Registry . . . . . . . . . . . . . . . 14 6.3. Form Relation Type Registry . . . . . . . . . . . . . . . 15 6.3.1. Registering New Form Relation Types . . . . . . . . . 15 6.3.2. Initial Registry Contents . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 7.2. Informative References . . . . . . . . . . . . . . . . . 17 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction Representational State Transfer (REST) [16] is an architectural style for distributed hypermedia systems. Over the years, REST has gained popularity not only as an approach for large-scale information dissemination, but also as the basic principle for designing and building Internet-based applications in general. Hartke Expires August 16, 2017 [Page 2] Internet-Draft CoRE Application Descriptions February 2017 In the coming years, the size and scope of the Internet is expected to greatly increase as physical-world objects become smart enough to communicate over the Internet -- a phenomenon known as the Internet of Things (IoT). As things learn to speak the languages of the net, the idea of applying REST principles to the design of IoT application architectures suggests itself. To this end, the Constrained Application Protocol (CoAP) [24] was created, an application-layer protocol that enables RESTful applications in constrained-node networks [10], thus giving rise to a new setting for Internet-based applications: the Constrained RESTful Environment (CoRE). To realize the full benefits and advantages of the REST style, a set of constraints needs to be maintained when designing new applications and their application programming interfaces (APIs). One of the fundamental principles is that "REST APIs must be hypertext-driven" [17]. This principle is often ignored by application designers, who instead specify their APIs out-of-band in terms of fixed URI patterns, e.g., in the API documentation or in a machine-readable format that facilitates code generation. Although this approach may appear easy for clients to use, the fixed resource names and data formats lead to a tight coupling between client and server implementations and make the system less flexible. Violations of REST design principles like this result in APIs that may not be as scalable, extensible, and interoperable as promised by REST [20]. REST is intended for long-lived network-based applications that span multiple organizations [17]. Principled REST APIs require some design effort, since application designers do not only have to take current requirements into consideration, but also have to anticipate changes that may be required in the future -- years or even decades after the application has been deployed for the first time. The reward is long-term stability and evolvability, both of which are very desirable features in the Internet of Things. To aid application designers in the design process, this document proposes CoRE Application Descriptions, a convention for describing the APIs of RESTful, hypermedia-driven Web applications. CoRE Application Descriptions help application designers avoid common mistakes by focusing almost all of the descriptive effort on defining the Internet media type(s) that are used for representing resources and driving application state. A template provides a consistent format for the description of APIs so that implementers can easily build interoperable clients and servers and other application designers can reuse application components in their own applications. Hartke Expires August 16, 2017 [Page 3] Internet-Draft CoRE Application Descriptions February 2017 2. Application Descriptions A CoRE Application Description is a named set of reusable components. It describes a contract between a server hosting an instance of the described application and clients that wish to interface with that instance. A CoRE Application Description is comprised of: o URI schemes that identify communication protocols, o Internet media types that identify representation formats, o link relation types that identify link semantics, o form relation types that identify form semantics, o variable names that identify the semantics of variables in templated links, o form field names that identify the semantics of form fields in forms, and o optionally, well-known locations. Together, these components provide the specific, in-band instructions for interfacing with a given application. 2.1. URI Schemes The foundation of a hypermedia-driven REST API are the communication protocol(s) spoken between a client and a server. Although HTTP/1.1 [14] is by far the most common communication protocol for REST APIs, a REST API should typically not be dependent on any specific communication protocol. The use of a particular protocol by a client is guided by URI schemes [7]. URI schemes specify the syntax and semantics of URI references [1] that the server includes in links (Section 2.2.2) and forms (Section 2.2.3). A URI scheme refers to a family of protocols, typically distinguished by a version number. For example, the "http" URI scheme refers to the two members of the HTTP family of protocols: HTTP/1.1 [14] and HTTP/2 [8] (as well as some predecessors). The specific HTTP version used is negotiated between a client and a server in-band using the version indicator in the HTTP request-line or the TLS Application- Layer Protocol Negotiation (ALPN) extension [18]. Hartke Expires August 16, 2017 [Page 4] Internet-Draft CoRE Application Descriptions February 2017 IANA maintains a list of registered URI schemes at . 2.2. Internet Media Types One of the most important aspect of hypermedia-driven communications is the concept of Internet media types [2]. Media types are used to label representations so that it is known how the representation should be interpreted and how it is encoded. The centerpiece of a CoRE Application Description should be one or more media types. A media type identifies a versioned series of representation formats (Section 2.2.1): a media type does not identify a particular version of a representation format; rather, the media type identifies the family, and includes provisions for version indicator(s) embedded in the representations themselves to determine more precisely the nature of how the data is to be interpreted [21]. A new media type is only needed to designate a completely incompatible format [21]. Note: The terms media type and representation format are often used interchangeably. In this document, the term "media type" refers specifically to a string of characters such as "application/xml" that is used to label representations; the term "representation format" refers to the definition of the syntax and semantics of representations, such as XML 1.0 [12] or XML 1.1 [13]. Media types consist of a top-level type and a subtype, structured into trees [2]. Optionally, media types can have parameters. For example, the media type "text/plain; charset=utf-8" is a subtype for plain text under the "text" top-level type in the standards tree and has a parameter "charset" with the value "utf-8". Media types can be further refined by o structured type name suffixes (e.g., "+xml" appended to the base subtype name; see Section 4.2.8 of RFC 6838 [2]), o a "profile" parameter (see Section 3.1 of RFC 6906 [25]), o subtype information embedded in the representations themselves (e.g., "xmlns" declarations in XML documents [11]), or a similar annotation. An annotation directly in the media type is generally preferable, since subtype information embedded in representations can typically not be negotiated during content negotiation (e.g., using the CoAP Accept option). Hartke Expires August 16, 2017 [Page 5] Internet-Draft CoRE Application Descriptions February 2017 In CoAP, media types are combined with content coding information [15] to indicate the "content format" [24] of a representation. Each content format is assigned a numeric identifier that can be used instead of the (typically much longer) textual name of the media type in representation formats with space constraints. The flat number space loses the structural information that the textual names have, however. The media type of a representation must be determined from in-band information (e.g., from the CoAP Content-Format option). Clients must not assume a structure from the application context or other out-of-band information. IANA maintains a list of registered Internet media types at . IANA maintains a list of registered structured suffixes at . IANA maintains a list of registered CoAP content formats at . 2.2.1. Representation Formats In RESTful applications, clients and servers exchange representations that capture the current or intended state of a resource and that are labeled with a media type. A representation is a sequence of bytes whose structure and semantics are specified by a representation format: a set of rules for encoding information. Representation formats should generally allow clients with different goals, so they can do different things with the same data. The specification of a representation format "describes a problem space, not a prescribed relationship between client and server. Client and server must share an understanding of the representations they're passing back and forth, but they don't need to have the same idea of what the problem is that needs to be solved." [22] Representation formats and their specifications frequently evolve over time. It is part of the responsibility of the designer of a new version to insure both forward and backward compatibility: new representations should work reasonably (with some fallback) with old processors and old representations should work reasonably with new processors [21]. Representation formats enable hypermedia-driven applications when they support the expression of hypermedia controls, i.e., links (Section 2.2.2) and forms (Section 2.2.3). Hartke Expires August 16, 2017 [Page 6] Internet-Draft CoRE Application Descriptions February 2017 2.2.2. Links As described in RFC 5988 [5], a link is a typed connection between two resources. Additionally, a link is the primary means for a client to navigate from one resource to another. A link is comprised of: o a link context (usually the "current" resource), o a link relation type that identifies the semantics of the link (see Section 2.3), o a link target, identified by a URI, and o optionally, target attributes that further describe the link or the link target. A link can be viewed as a statement of the form "{link context} has a {link relation type} resource at {link target}, which has {target attributes}" [5]. For example, the resource could have a "terms-of-service" resource at , which has a representation with the media type "text/html". There are two special kinds of links: o An embedding link is a link with an additional hint: when the link is processed, it should be substituted with the representation of the referenced resource rather than cause the client to navigate away from the current resource. Thus, traversing an embedding link adds to the current state rather than replacing it. The most well known example for an embedding link is the HTML element. When a Web browser processes this element, it automatically dereferences the "src" and renders the resulting image in place of the element. o A templated link is a link where the client constructs the link target URI from provided in-band instructions. The specific rules for such instructions are described by the representation format. URI Templates [3] provide a generic way to construct URIs through variable expansion. Templated links allow a client to construct resource URIs without being coupled to the resource structure at the server, provided that the client learns the template from a representation sent by the server and does not have the template hard-coded. Hartke Expires August 16, 2017 [Page 7] Internet-Draft CoRE Application Descriptions February 2017 2.2.3. Forms A form is the primary means for a client to submit information to a server, typically in order to change resource state. A form is comprised of: o a form context (usually the "current" resource), o a form relation type that identifies the semantics of the form (see Section 2.4), o a form target, identified by a URI, o a submission method (PUT, POST, PATCH, FETCH, or DELETE), o a description of a representation that the server expects as part of the form submission, and o optionally, target attributes that further describe the form or the form target. A form can be viewed as an instruction of the form "To {form relation type} the {form context}, make a {method} request to {form target}, which has {target attributes}". For example, to "update" the resource , a client could be required to make a PUT request to . (In many cases, the target of a form is the same resource as the context, but this is not required.) The description of the expected representation can be a set of form fields (see Section 2.4.1) or simply a list of acceptable media types. Note: A form with a submission method of GET is, strictly speaking, a templated link, since it provides a way to construct a URI and does not submit a representation to the server. 2.3. Link Relation Types A link relation type identifies the semantics of a link [5]. For example, a link with the relation type "copyright" indicates that the resource identified by the target URI is a statement of the copyright terms applying to the link context. Relation types are not to be confused with media types; they do not identify the format of the representation that results when the link Hartke Expires August 16, 2017 [Page 8] Internet-Draft CoRE Application Descriptions February 2017 is dereferenced [5]. Rather, they only describe how the link context is related to another resource [5]. IANA maintains a list of registered link relation types at . Applications that don't wish to register a link relation type can use an extension link relation type [5], which is a URI that uniquely identifies the link relation type. For example, an application can use the string "http://example.com/foo" as link relation type without having to register it. Using a URI to identify an extension link relation type, rather than a simple string, reduces the probability of different link relation types using the same identifiers. In order to minimize the overhead of link relation types in representation formats with space constraints, IANA-registered link relation types are assigned a numeric identifier that can be used in place of the textual name (see also Section 6.2). For example, the link relation type "copyright" has the number 12. A representation format may additionally provide numeric identifiers for extension link relation types. 2.3.1. Template Variable Names A templated link enables clients to construct the target URI of a link, for example, when the link refers to a space of resources rather than a single resource. The most prominent mechanisms for this are URI Templates [3] and the HTML
element with a submission method of GET. To enable an automated client to construct an URI reference from a URI Template, the name of the variable in the template can be used to identify the semantics of the variable. For example, when retrieving the representation of a collection of temperature readings, a variable named "threshold" could indicate the variable for setting a threshold of the readings to retrieve. Template variable names are scoped to link relation types, i.e., two variables with the same name can have different semantics if they appear in links with different link relation types. 2.4. Form Relation Types A form relation type identifies the semantics of a form. For example, a form with the form relation type "create-item" indicates that a new item can be created within the form context by making a request to the resource identified by the target URI. Hartke Expires August 16, 2017 [Page 9] Internet-Draft CoRE Application Descriptions February 2017 IANA maintains a list of registered form relation types at . Similar to extension link relation types, applications can use extension form relation types when they don't wish to register a form relation type. IANA-registered form relation types are assigned a numeric identifier that can be used in place of the textual name. For example, the form relation type "update" has the number 3. A representation format may additionally provide numeric identifiers for extension form relation types. 2.4.1. Form Field Names Forms can have a detailed description of the representation expected by the server as part of form submission. This description typically consists of a set of form fields where each form field is comprised of a field name, a field type, and optionally a number of attributes such as a default value, a validation rule or a human-readable label. To enable an automated client to fill out a form, the field name can be used to identify the semantics of the form field. For example, when controlling a smart light bulb, the field name "brightness" could indicate the field for setting the desired brightness of the light bulb. Field names are scoped to form relation types, i.e., two form fields with the same name can have different semantics if they appear in forms with different form relation types. The type of a form field is a data type such as "an integer between 1 and 100" or "a RGB color". The type is orthogonal to the field name, i.e., the type should not be determined from the field name even though the client can identify the semantics of the field from the name. This separation makes it easy to change the set of acceptable values in the future. 2.5. Well-Known Locations Some applications may require the discovery of information about a host, known as "site-wide metadata" in RFC 5785 [4]. For example, RFC 6415 [19] defines a metadata document format for describing a host; similarly, RFC 6690 [23] defines a link format for the discovery of resources hosted by a server. Applications that need to define a resource for this kind of metadata can register new "well-known locations". RFC 5785 [4] defines the Hartke Expires August 16, 2017 [Page 10] Internet-Draft CoRE Application Descriptions February 2017 path prefix "/.well-known/" in "http" and "https" URIs for this purpose. RFC 7252 [24] extends this convention to "coap" and "coaps" URIs. IANA maintains a list of registered well-known URIs at . 3. Application Description Template As applications are implemented and deployed, it becomes important to describe them in some structured way. This section provides a simple template for CoRE Application Descriptions. A uniform structure allows implementers to easily determine the components that make up the interface of an application. The template below lists all components of applications that both the client and the server implementation of the application need to understand in order to interoperate. Crucially, items not listed in the template are not part of the contract between clients and servers -- they are implementation details. This includes in particular the URIs of resources (see Section 4). CoRE Application Descriptions are intended to be published in human- readable format by designers of applications and by operators of deployed application instances. Application designers may publish an application description as a general specification of all application instances, so that implementers can create interoperable clients and servers. Operators of application instances may publish an application description as part of the API documentation of the service, which should also include instructions how the service can be located and which communication protocols and security modes are used. The fields of the template are as follows: Application name: Name of the application. The name is not used to negotiate capabilities; it is purely informational. A name may include a version number or, for example, refer to a living standard that is updated continuously. URI schemes: URI schemes identifying the communication protocols that need to be understood by clients and servers. This information is mostly relevant for deploymed instances of the application rather than for the general specification of the application. Media types: Hartke Expires August 16, 2017 [Page 11] Internet-Draft CoRE Application Descriptions February 2017 Internet media types that identify the representation formats that need to be understood by clients and servers. An application description must comprise at least one media type. Additional media types may be required or optional. Link relation types: Link relation types that identify the semantics of links. An application description may comprise IANA-registered link relation types and extension link relation types. Both may be required or optional. Template variable names: For each link relation type, variable names that identify the semantics of variables in templated links with that link relation type. Whether a template variable is required or optional is indicated in-band inside the templated link. Form relation types: Form relation types that identify the semantics of forms and, for each form relation type, the submission method(s) to be used. An application description may comprise IANA-registered form relation types and extension form relation types. Both may be required or optional. Form field names: For each form relation type, form field names that identify the semantics of form fields in forms with that form relation type. Whether a form field is required or optional is indicated in-band inside the form. Well-known locations: Well-known locations in the resource identifier space of servers that clients can use to discover information given the DNS name or IP address of a server. Interoperability considerations: Any issues regarding the interoperable use of the components of the application should be given here. Security considerations: Security considerations for the security of the application must be specified here. Contact: Person (including contact information) to contact for further information. Author/Change controller: Hartke Expires August 16, 2017 [Page 12] Internet-Draft CoRE Application Descriptions February 2017 Person (including contact information) authorized to change this application description. Each field should include full citations for all specifications necessary to understand the application components. 4. URI Design Considerations URIs [1] are a cornerstone of RESTful applications. They enable uniform identification of resources via URI schemes [7] and are used every time a client interacts with a particular resource or when a resource representation references another resource. URIs often include structured application data in the path and query components, such as paths in a filesystem or keys in a database. It is common for many RESTful applications to use these structures not only as an implementation detail but also make them part of the public REST API, prescribing a fixed format for this data. However, there are a number of problems with this practice [6], in particular if the application designer and the server owner are not the same entity. In hypermedia-driven applications, URIs are therefore not included in the application interface. A CoRE Application Description must not mandate any particular form of URI substructure. RFC 7320 [6] describes the problematic practice of fixed URI structures in detail and provides some acceptable alternatives. Nevertheless, the design of the URI structure on a server is an essential part of implementing a RESTful application, even though it is not part of the application interface. The server implementer is responsible for binding the resources identified by the application designer to URIs. A good RESTful URI is: o Short. Short URIs are easier to remember and cause less overhead in requests and representations. o Meaningful. A URI should describe the resource in a way that is meaningful and useful to humans. o Consistent. URIs should follow a consistent pattern to make it easy to reason about the application. o Bookmarkable. Cool URIs don't change [9]. However, in practice, application resource structures do change. That should cause URIs Hartke Expires August 16, 2017 [Page 13] Internet-Draft CoRE Application Descriptions February 2017 to change as well so they better reflect reality. Implementations should not depend on unchanging URIs. o Shareable. A URI should not be context sensitive, e.g., to the currently logged-in user. It should be possible to share a URI with third parties so they can access the same resource. o Extension-less. Some applications return different data for different extensions, e.g., for "contacts.xml" or "contacts.json". But different URIs imply different resources. RESTful URIs should identify a single resource. Different representations of the resource can be negotiated (e.g., using the CoAP Accept option). 5. Security Considerations The security considerations of RFC 3986 [1], RFC 5785 [4], RFC 5988 [5], RFC 6570 [3], RFC 6838 [2], RFC 7320 [6], and RFC 7595 [7] are inherited. All components of an application description are expected to contain clear security considerations. CoRE Application Descriptions should furthermore contain security considerations that need to be taken into account for the security of the overall application. 6. IANA Considerations [Note to RFC Editor: Please replace XXXX in this section with the RFC number of this specification.] 6.1. Content-Format Registry RFC 6838 [2] establishes a IANA registry for media types. Many of these media types are also useful in constrained environments as CoAP content formats. RFC 7252 [24] establishes a IANA registry for these content formats. This specification tasks IANA with the allocation of a content format for any existing or new media type registration that does not define any parameters (required or optional). The content formats shall be allocated in the range 1000-9999. 6.2. Link Relation Type Registry RFC 5988 [5] establishes a IANA registry for link relation types. This specification extends the registration template with a "Relation ID": a numeric identifier that can be used instead of the "Relation Name" to identify a link relation type. IANA is tasked with the assignment of an ID to any existing or new link relation type. The IDs shall be assigned in the range 1-9999. Hartke Expires August 16, 2017 [Page 14] Internet-Draft CoRE Application Descriptions February 2017 6.3. Form Relation Type Registry This specification establishes a IANA registry for form relation types. 6.3.1. Registering New Form Relation Types Form relation types are registered in the same way as link relation types [5], i.e., they are registered on the advice of a Designated Expert with a Specification Required. The requirements for registered relation types are adopted from Section 4.1 of RFC 5988 [5]. The registration template is: o Relation Name: o Relation ID: o Description: o Reference: o Notes: [optional] The IDs shall be assigned in the range 1-9999. 6.3.2. Initial Registry Contents The Form Relation Type registry's initial contents are: o Relation Name: create-item Relation ID: 1 Description: Refers to a resource that can be used to create a resource in a collection of resources. Reference: [RFCXXXX] o Relation Name: delete Relation ID: 2 Description: Refers to a resource that can be used to delete a resource in a collection of resources. Reference: [RFCXXXX] o Relation Name: update Relation ID: 3 Description: Refers to a resource that can be used to update the state of the form context. Hartke Expires August 16, 2017 [Page 15] Internet-Draft CoRE Application Descriptions February 2017 Reference: [RFCXXXX] o Relation Name: search Relation ID: 4 Description: Refers to a resource that can be used to search the form context. Reference: [RFCXXXX] 7. References 7.1. Normative References [1] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [2] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [3] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, . [4] Nottingham, M. and E. Hammer-Lahav, "Defining Well-Known Uniform Resource Identifiers (URIs)", RFC 5785, DOI 10.17487/RFC5785, April 2010, . [5] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . [6] Nottingham, M., "URI Design and Ownership", BCP 190, RFC 7320, DOI 10.17487/RFC7320, July 2014, . [7] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . Hartke Expires August 16, 2017 [Page 16] Internet-Draft CoRE Application Descriptions February 2017 7.2. Informative References [8] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", RFC 7540, DOI 10.17487/RFC7540, May 2015, . [9] Berners-Lee, T., "Cool URIs don't change", 1998, . [10] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . [11] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. Thompson, "Namespaces in XML 1.0 (Third Edition)", World Wide Web Consortium Recommendation REC-xml-names-20091208, December 2009, . [12] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC- xml-20081126, November 2008, . [13] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., Yergeau, F., and J. Cowan, "Extensible Markup Language (XML) 1.1 (Second Edition)", World Wide Web Consortium Recommendation REC-xml11-20060816, August 2006, . [14] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, . [15] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . [16] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . Hartke Expires August 16, 2017 [Page 17] Internet-Draft CoRE Application Descriptions February 2017 [17] Fielding, R., "REST APIs must be hypertext-driven", October 2008, . [18] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [19] Hammer-Lahav, E., Ed. and B. Cook, "Web Host Metadata", RFC 6415, DOI 10.17487/RFC6415, October 2011, . [20] Li, L., Wei, Z., Luo, M., and W. Chou, "Requirements and Design Patterns for REST Northbound API in SDN", draft-li- sdnrg-design-restapi-02 (work in progress), July 2016. [21] Masinter, L., "MIME and the Web", draft-masinter-mime-web- info-02 (work in progress), January 2011. [22] Richardson, L. and M. Amundsen, "RESTful Web APIs", O'Reilly Media, ISBN 978-1-4493-5806-8, September 2013. [23] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, . [24] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [25] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, DOI 10.17487/RFC6906, March 2013, . Acknowledgements Jan Algermissen, Mike Amundsen, Mike Kelly, Julian Reschke, and Erik Wilde provided valuable input on link and form relation types. Thanks to Olaf Bergmann, Carsten Bormann, Stefanie Gerdes, Ari Keranen, Michael Koster, Matthias Kovatsch, Teemu Savolainen, and Bilhanan Silverajan for helpful comments and discussions that have shaped the document. Some of the text in this document has been borrowed from [5], [6], [17], [20], and [21]. All errors are my own. Hartke Expires August 16, 2017 [Page 18] Internet-Draft CoRE Application Descriptions February 2017 This work was funded in part by Nokia. Author's Address Klaus Hartke Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany Phone: +49-421-218-63905 Email: hartke@tzi.org Hartke Expires August 16, 2017 [Page 19]