Internet Engineering Task Force L. Svensson Internet-Draft Intended status: Informational R. Verborgh Expires: September 10, 2021 Ghent University - imec H. Van de Sompel Data Archiving and Networked Services March 9, 2021 Indicating, Discovering, Negotiating, and Writing Profiled Representations draft-svensson-profiled-representations-01 Abstract This document details approaches for enriching HTTP interactions with information pertaining to the profiles to which resource representations conform. It surveys approaches that were recently introduced to indicate the profile of a resource representation, and to make representations that conform to a profile discoverable. It introduces a generally applicable approach to negotiate for a resource representation that conforms to a profile preferred by a user agent. That approach leverages the existing content negotiation mechanism but applies it to the profile dimension to which it was previously not applied. The document also shows how a server can convey which profiled representations it is able to accept from a user agent. 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 https://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 September 10, 2021. Svensson, et al. Expires September 10, 2021 [Page 1] Internet-Draft Handling Profiled Representations March 2021 Copyright Notice Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Notational Conventions . . . . . . . . . . . . . . . . . 5 2. Indicating Profiled Representations . . . . . . . . . . . . . 5 3. Discovering Profiled Representations . . . . . . . . . . . . 7 4. Negotiating for Profiled Representations . . . . . . . . . . 7 4.1. Profile Negotiation Details . . . . . . . . . . . . . . . 8 4.1.1. Proactive Profile Negotiation . . . . . . . . . . . . 9 4.1.2. Reactive Profile Negotiation . . . . . . . . . . . . 12 4.2. Accept-Profile HTTP Header Syntax . . . . . . . . . . . . 14 5. Writing Profiled Representations . . . . . . . . . . . . . . 14 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Any given web resource can typically be represented in a variety of ways. For example, the same information could be rendered according to different media types, say, as XML or JSON. But in many cases, variations in representation other than those inherent to a given media type are also possible. For example, the same structured data could be rendered in XML according to different XML Schema [W3C.REC-xmlschema11-1-20120405]. Or the same RDF graph could be expressed on the basis of different vocabularies. Svensson, et al. Expires September 10, 2021 [Page 2] Internet-Draft Handling Profiled Representations March 2021 This dimension of variability regarding representations that goes beyond media types has been acknowledged for quite some time. For example, in 2000, the Dublin Core Metadata Initiative (DCMI) introduced "Application Profiles" to explicitly acknowledge that the same metadata can be represented in various ways and defined them as "schemas which consist of data elements drawn from one or more namespaces, combined together by implementers, and optimised for a particular local application" [HeeryAndPatel]. 1.1. Terminology Inspired by the term used in [RFC6906] to refer to this extra dimension of variability, this document uses the term "profile" to mean a description of structural and/or semantic constraints on representations of resources that apply in addition to the constraints inherently indicated by their MIME type: o Profiles can be dependent on a media type. For example, this is the case for XML, with constraints being expressed using an XML Schema. This is also the case for JSON that offers a wide range of options regarding the use of tree structure, keys, and value types. In these cases, the meaning of the term "profile" intended by this document coincides with the use of the same term in [RFC6906]. o Profiles can be independent of media type. For example, this is the case for RDF graphs that can be rendered according to various media types, while constraints can be expressed in a manner that is independent of media type, among others, using SHACL [W3C.REC-shacl-20170720]. In these cases, the meaning of the term "profile" intended by this document is a slight extension of the one intended by [RFC6906]. 1.2. Purpose When it comes to HTTP interactions, profiles have received little attention despite their de facto existence and the added-value they can bring for building rich applications. Such applications benefit from knowledge regarding the nature of a representation that a client obtains from a server, that a client sends to a server, and that a server is willing to accept from a client, beyond what is conveyed by the representation's MIME type. These applications are also be helped by an ability to discover representations rendered according to a profile they can handle, or, optimally, an ability to explicitly request a rendering according to a preferred profile. A common approach to handle profiles is to register them as a media type, dedicated to the combination of an actual media type and a Svensson, et al. Expires September 10, 2021 [Page 3] Internet-Draft Handling Profiled Representations March 2021 profile of it. Media types that illustrate this approach include "application/activity+json", "application/calendar+json", and "application/calendar+xml. This approach allows conveying all necessary profile information in HTTP interactions, e.g. using the "Accept" and "Content-Encoding" HTTP headers and the "type" attribute for web links. As such it supports indicating, discovering, and content negotiating (in the media type dimension) for profiled representations. This registration-based approach may be feasible for profiles that are expected to be very widely used but is not practical in case support for many different profiles is required. Also, the "calendar" examples illustrate that the registration-based approach is not ideal when a profile applies to multiple media types. And, the "activity" example illustrates that the approach supports indicating what the major ingredient of a profiled representation is (i.e. the ActivityStreams Vocabulary) but becomes problematic when indications are also needed regarding additional vocabularies used in representations. Another approach to handle profiles leverages the ability provided by [RFC6838] to register parameters when registering a media type. Some media types have used this capability to register an attribute dedicated to conveying profiles of the media type. For example, for "application/ld+json" the "profile" parameter has been registered for this purpose. The approach provides flexibility for handling many profiles, including ones that are not yet known when registering the media type. It also supports indicating, discovering, and content negotiating (in the media type dimension) for profiled representations using common approaches. But the approach remains problematic because it ties profile information to a media type, depends on registering a parameter to convey profile information when registering a new media type, and, realistically, on the registration of the same parameter name (i.e. "profile" as suggested in [RFC6906]) for all media types for which registrants deem that conveying profile information is important. Additionaly, [RFC6838] discourages registering parameters for previously registered media types, making it highly questionable that a uniform attribute to convey profile information across all media types could retroactively be defined. Recognizing the importance of profiles and the problems with the aforementioned approaches to handle them, specifications have started to introduce alternative approaches to express information about resource representation profiles in HTTP interactions: o [RFC6906] introduces the "profile" link relation type that is generally applicable for indicating the profile of a resource representation that is sent by a client to a server or by a server to a client. Svensson, et al. Expires September 10, 2021 [Page 4] Internet-Draft Handling Profiled Representations March 2021 o [I-D.nottingham-link-hint] introduces a capability to make profiled representations discoverable via web links by using the "formats" attribute to express the profile of a linked resource. Section 2 and Section 3 provide a concise overview of the approaches introduced by [RFC6906] and [I-D.nottingham-link-hint], to respectively indicate and discover the profile of resource representations. Section 4 specifies a generally applicable approach to negotiate for representations that conform to a profile preferred by a user agent. Section 5 shows how servers can convey which profiled representations they are able to accept from user agents. 1.3. Notational Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This specification uses the terms "link context" and "link target" as defined in [RFC8288]. These terms respectively correspond with "Context IRI" and "Target IRI" as used in [RFC5988]. Although defined as IRIs, in common scenarios they are also URIs. In the examples provided in this document, links in the HTTP "Link" header are shown on separate lines in order to improve readability. Note, however, that as per Section 3.2 of [RFC7230], line breaks are not allowed in values for HTTP headers; only whitespaces and tabs are supported as seperators. 2. Indicating Profiled Representations As per [RFC6906], a web link with a "profile" link relation type can be used to indicate the profile of a representation that is exchanged in HTTP interactions. Figure 1 shows a client requesting a representation from a server and Figure 2 shows the server responding. The response includes a "Link" header ([RFC8288]) that contains a link with the "profile" relation type. The link target indicates the profile of the response body (not shown). Figure 3 shows a client submitting a representation to a server, using the same approach to express the profile to which that representation complies. Section 5 describes how a server can convey the profiles it supports for representations that are submitted by a user agent. Svensson, et al. Expires September 10, 2021 [Page 5] Internet-Draft Handling Profiled Representations March 2021 GET /some/resource HTTP/1.1 Host: example.org Connection: close Figure 1: Client requests a representation HTTP/1.1 200 OK Content-Type: application/xml ; charset=utf-8 Link: ; rel="profile" Content-Length: 23364 Connection: close ... Figure 2: Server indicates the profile of the returned representation PUT /some/resource HTTP/1.1 Host: example.org Content-Type: application/xml ; charset=utf-8 Link: ; rel="profile" Content-Length: 23364 Connection: close ... Figure 3: Client indicates the profile of a representation submitted to a server In some cases organisations use separate servers to perform content negotiation and to deliver resources, e. g. when static content is served through content delivery networks. The servers that perform the content negotiation interact with the client requesting the resource and then typically refer to the correct representation using a 303 redirect. In those cases the servers that deliver the representations are not profile aware and thus cannot add the appropriate "Link" headers to the response. Instead the server performing the negotiation will have to supply that information. This is done by adding an "anchor" attribute pointing to the representation the link header refers to. Figure 4 shows the response to a Figure 1 where the server performing the negotiation redirects the client to the resource specified in the "Location" header and by using the same URI in the "anchor" attribute of the "Link" header indicates that the information in the "Link" header does not apply to this response but to the resource redirected to. Svensson, et al. Expires September 10, 2021 [Page 6] Internet-Draft Handling Profiled Representations March 2021 HTTP/1.1 300 See other Location: https://static.example.org/other/resource Link: ; rel="profile" ; anchor="https://static.example.org/other/resource" ... Figure 4: Server indicates the profile of the representation referred to in the 'Location' header 3. Discovering Profiled Representations The link hints capability introduced in [I-D.nottingham-link-hint], can be leveraged by a server to make profiled representations discoverable by including a "formats" attribute on web links. Figure 5 shows a response to the client request of Figure 1 in which the server uses this technique. The "Link" header indicates the profile of the returned representation but also points at two alternative representations, each of which conforms to another profile. HTTP/1.1 200 OK Content-Type: application/xml Link: ; rel="profile" , ; rel="alternate" ; type="application/xml" ; formats="http://example.org/our_internal_xml_profile" , ; rel="alternate" ; formats="http://example.org/our_community_profile" Content-Length: 23364 Connection: close ... Figure 5: Server makes profiled representations discoverable 4. Negotiating for Profiled Representations Section 1.2 describes two approaches for conveying profile information in HTTP interactions that make it possible to negotiate for profiled representations by applying content negotiation in the media type dimension. It also indicates the restricted applicability of these approaches, in both cases a result of their direct dependence on the media type registration process. Svensson, et al. Expires September 10, 2021 [Page 7] Internet-Draft Handling Profiled Representations March 2021 This section describes an approach that applies content negotiation in a dimension that it was previously not applied to. The profile negotiation approach introduced here is generally applicable for resource representations, irrespective of media type. These are its core aspects: o In order to allow a user agent to inform a server about its preferences regarding profiles for resource representations, the "Accept-Profile" HTTP header introduced here is used. A user agent can specify several profiles and use quality indicators (q-values) to indicate preferences. o In order to allow a server to express its support for profile negotiation the "Vary" HTTP header is used, in this case, with the "Accept-Profile" value. o In order to allow a server to convey the profile of a representation delivered to a user agent, rather than introducing a server-side counterpart to the client-side "Accept-Profile" header, the existing "profile" link approach introduced by [RFC6906] is used. If a representation conforms to multiple profiles, a distinct "profile" link is used per profile; the order in which these links are provided has no relevance. o In order to allow a server to convey the profiles it supports, web links with the "formats" link hint introduced in [I-D.nottingham-link-hint] are used to convey the profiles of the link target resources. This approach uniformely applies to reponses to HTTP HEAD/GET/PUT/POST/PATCH. o Throughout the profile negotiation approach, a profile MUST be referred to by a URI. This is the case for the content of the "Accept-Profile" HTTP header, for the target of web links with the "profile" link relation, and for the content of the "formats" link hint for web links. 4.1. Profile Negotiation Details Profile negotiation uses the content negotiation processes described in Section 3.4 of RFC 7231 [RFC7231] but applies them to the profile dimension. Both proactive negotiation and reactive negotiation for profiles can be supported by servers. Both are described in more detail in the remainder of this section. In profile negotiation, a profile MUST be referred to by a URI that, from here onwards, is named a profile URI. If the profile URI is dereferencable it SHOULD lead to a document that details the profile. If the profile URI is not dereferencable (e.g. a URN [RFC8141] or an Svensson, et al. Expires September 10, 2021 [Page 8] Internet-Draft Handling Profiled Representations March 2021 info-URI [RFC4452]) facilities SHOULD be available to allow user agents and servers to understand their meaning, e.g. community registries of profiles. 4.1.1. Proactive Profile Negotiation In proactive profile negotiation, the user agent uses the "Accept- Profile" HTTP header to inform the server about the agent's preference regarding profiles to be used for representing a resource in the server's response. In case a user agent wants to express a preference for a single profile, the value of the header is that profile's URI. In case a user agent wants to express a preference for multiple profiles, the value of the header is a list containing each profile's URI, seperated by commas. Alternatively, multiple "Accept-Profile" HTTP headers can be used, each conveying a single profile URI. Quality indicators (q-values) MAY be used to rank profile preferences. The order in which profile URIs are conveyed or the duplicate mentioning of a same profile URI MUST NOT be interpreted as significant. A server that supports proactive profile negotiation for the resource that a user agent interacts with: o MUST include a "Vary" HTTP header containing the value "accept- profile" in its response to the user agent. o MUST include a "Link" HTTP header containing a link with the "profile" relation type that has as link target the profile URI of the resource representation returned to the user agent. In case the representation conforms to additional profiles known to the server, such a "profile" link SHOULD be included for each. o SHOULD convey the availability of alternate profiled representations of the resource by using the link hint approach described in Section 4.1.2. These requirements for servers that support proactive profile negotiation also apply when: o The user agent expressed a profile preference in its request by using an "Accept-Profile" header but the server cannot return a representation that conforms to a preferred profile. o The user agent did not express a profile preference using an "Accept-Profile" header in its request. A user agent SHOULD interpret the abscence of a "Vary" HTTP header with an "accept-profile" value in a response from a server as the Svensson, et al. Expires September 10, 2021 [Page 9] Internet-Draft Handling Profiled Representations March 2021 lack of support for profile negotiation for the resource the user agent interacts with. A server SHOULD consider representations that do not conform to any of the profiles listed by a user agent in an "Accept-Profile" header as non-interpretable by the agent. As such, honoring the user agent preferences in the profile dimension SHOULD take precedence over honoring content negotiation in other dimensions. In Figure 6 a user agent requests an RDF serialization from a server and expresses preference for two media types using the "Accept" header and two profiles using the "Accept-Profile" header. It uses q-values to express a preference for the profile with profile URI over the one with profile URI . GET /document HTTP/1.1 Host: example.org Accept: text/turtle, application/rdf+xml Accept-Profile: "http://example.org/shapes/shape-1" ; q=0.8 , "http://example.org/shapes/shape-2" ; q=0.5 Connection: close Figure 6: Client expresses a preference for two profiles Figure 7 shows the server's response to the request of Figure 6. By means of the "Vary" header, the server expresses support for negotiation in both the media type and profile dimensions. The "profile" link with link target indicates that the server was able to honor the user agent's second profile preference. Another "profile" link shows that the delivered representation also conforms to a profile with profile URI . Furthermore, using an "alternate" link, the server indicates support for another profile with as profile URI. Note that, even if the user agent does not express profile preferences using the "Accept-Profile" header and the server's "Vary" header would be the same, the "Link" header would still include a "profile" link to indicate the profile of the representation returned by the server. Svensson, et al. Expires September 10, 2021 [Page 10] Internet-Draft Handling Profiled Representations March 2021 HTTP/1.1 200 OK Content-Type: text/turtle Vary: Accept, Accept-Profile Link: ; rel="profile" , ; rel="profile" , ; rel="alternate" ; type="text/turtle" ; formats="http://example.org/shapes/shape-4" Content-Length: 8724 Connection: close ... Figure 7: Response honors a user agent's preference Figure 8 shows the response to the request of Figure 6 in case the server supports profile negotiation for the resource at hand but can not return a representation that conforms to a profile preferred by the user agent. The server has chosen to nevertheless return a representation that conforms to profile , which is not among the ones preferred by the user agent. The server also reveals the existence of a representation that conforms to profile . The server could also choose not to return a default representation in which case it would return a "406 Not Acceptable" HTTP response code and no response body. It would not provide any "profile" links but might use "alternate" links with a "formats" attribute to indicate the existence of supported profiles. Svensson, et al. Expires September 10, 2021 [Page 11] Internet-Draft Handling Profiled Representations March 2021 HTTP/1.1 200 OK Content-Type: text/turtle Vary: Accept, Accept-Profile Link: ; rel="profile" , ; rel="alternate" ; type="text/turtle" ; formats="http://example.org/shapes/shape-5" Content-Length: 6333 Connection: close ... Figure 8: Response does not honor a user agent's preference but includes default representation Figure 9 shows the response to the request of Figure 6 in case the server does not support profile negotiation for the resource . It does support negotiation in the media type dimension and has honoured one of the user agent's preferences with that regard, as can be seen by the "Vary" and "Content-Type" headers. HTTP/1.1 200 OK Content-Type: text/turtle Vary: Accept Content-Length: 8724 Connection: close ... Figure 9: Response indicates lack of support for proactive profile negotiation 4.1.2. Reactive Profile Negotiation In reactive profile negotiation, the user agent selects the profiled representation that best meets its preferences on the basis of a list of possible representations it obtains from the server. A server that supports reactive profile negotiation MUST provide such a list of supported profiled representation as a set of links in the "Link" header. Each of these links: o SHOULD have the "alternate" relation type. Svensson, et al. Expires September 10, 2021 [Page 12] Internet-Draft Handling Profiled Representations March 2021 o MUST use the "formats" link hint to convey the profile URI of the profile to which the resource that is the link target conforms. o SHOULD use the "allow" link hint to convey the HTTP methods that are supported by the resource that is the link target. Figure 10 shows a user agent issuing a HTTP HEAD on a resource in order to determine whether profiled representations are available for it. Figure 11 shows the response of a server that supports reactive profile negotiation. By means of "alternate" links in the "Link" header, the server indicates support for two profiled representations for the resource at hand, and, for each, indicates the URI at which they can be accessed, as well as their respective profile URIs, media types, and supported HTTP methods. On the basis of this response, the client can decide whether any of the linked resources conform to a preferred profile, and, if so, access the respective link target. Figure 12 shows the response to an HTTP HEAD issued on the link target of the first "alternate" link. HEAD /bibrecord/1 HTTP/1.1 Host: example.org Accept: application/xml Connection: close Figure 10: Client determines support for profiles HTTP/1.1 200 OK Content-Type: text/plain Link: ; rel="alternate" ; type="application/xml" ; formats="http://purl.org/dc/terms/" ; allow="HEAD,GET,PATCH" , ; rel="alternate" ; formats="http://id.loc.gov/ontologies/bibframe/" ; allow="HEAD,GET" Content-Length: 200 Connection: close Figure 11: Server supports two profiles Svensson, et al. Expires September 10, 2021 [Page 13] Internet-Draft Handling Profiled Representations March 2021 HTTP/1.1 200 OK Content-Type: application/xml Link: ; rel="profile" , ; rel="alternate" ; formats="http://id.loc.gov/ontologies/bibframe/" ; allow="HEAD,GET" Allow: HEAD, GET, PATCH Accept-Patch: application/xml-patch+xml Content-Length: 458 Connection: close Figure 12: Response to a client accessesing a profiled representation 4.2. Accept-Profile HTTP Header Syntax Figure 13 describes the syntax of the "Accept-Profile" HTTP header, using the grammar defined in RFC 5234 [RFC5234] and the rules defined in Section 3.2 of RFC 7230 [RFC7230]. The definitions of "URI- reference" and "weight" are imported from RFC 7230 [RFC7230] and RFC 7231 [RFC7231], respectively. Accept-Profile = "Accept-Profile" ":" OWS (accept-value) *(OWS "," OWS accept-value) OWS accept-value = "<" URI-reference ">" [weight] | accept-value-ext Figure 13: ABNF for the "Accept-Profile" HTTP header 5. Writing Profiled Representations A user agent that wants to submit a profiled representation to a server can use the reactive negotiation approach to determine the nature of a server's support with this regard. A server that allows user agents to submit profiled representations SHOULD follow the directions for reactive negotiation described in Section 4.1.2. A client that submits a representation that complies to a profile that was not advertised by the server by means of the reactive negotiation approach, SHOULD assume that the server is not able to process it. A server that fails a submission request due to receiving a payload with a profile that it does not support MUST respond with a "422 Svensson, et al. Expires September 10, 2021 [Page 14] Internet-Draft Handling Profiled Representations March 2021 Unprocessable Entity" HTTP status code and SHOULD use the approach described in Section 4.1.2 to convey profiles that are supported. Continuing from Figure 12, Figure 14 shows a user agent issuing a HTTP PATCH against resource in order to update it. It uses the "Content-Encoding" header to convey the XML Patch media type of its message body and a link with a "profile" relation type in the "Link" header to indicate the profile to which it conforms. Figure 15 shows the server's response, indicating that the patch was applied successfully; the server returns the updated representation as message body. PATCH /bibrecord/1/DC HTTP/1.1 Host: example.org Content-Encoding: application/xml-patch+xml Link: ; rel="profile" Accept: application/xml Content-Length: 321 Connection: close ... Figure 14: Client submits profiled representation HTTP/1.1 200 OK Content-Type: application/xml Content-Location: http://example.org/bibrecord/1/DC Link: ; rel=profile" , ; rel="alternate" ; formats="http://id.loc.gov/ontologies/bibframe/" ; allow="HEAD,GET" Allow: HEAD, GET, PATCH Accept-Patch: application/xml-patch+xml Content-Length: 592 Connection: close ... Figure 15: Server indicates successful submission of profiled representation by client If, in Figure 14, the user agent would have issued an HTTP PATCH on resource indicating that the Svensson, et al. Expires September 10, 2021 [Page 15] Internet-Draft Handling Profiled Representations March 2021 profile URI of the patch was , the response would have a 422 HTTP status code to express that the profile is not supported by the resource at hand. Such a response is shown in Figure 16. HTTP/1.1 422 Unprocessable Entity Content-Type: text/plain Link: ; rel="alternate" ; type="application/xml" ; formats="http://purl.org/dc/terms/" ; allow="HEAD,GET,PATCH" Content-Length: 110 Connection: close ... Figure 16: Server indicates unsuccessful submission of profiled representation by client 6. IANA Considerations This memo requires IANA to register the Accept-Profile HTTP header defined in Section 4.2 in the appropriate IANA registry: o Header Field Name: Accept-Profile o Applicable Protocol: Hypertext Transfer Protocol (HTTP) o Status: Informational o Author/Change controller: IETF o Specification document(s): this document 7. Security Considerations 8. Acknowledgments Many thanks to our colleagues for feedback: Enno Meijers, Michael L. Nelson 9. References Svensson, et al. Expires September 10, 2021 [Page 16] Internet-Draft Handling Profiled Representations March 2021 9.1. Normative References [I-D.nottingham-link-hint] Nottingham, M., "HTTP Link Hints", draft-nottingham-link- hint-02 (work in progress), March 2020. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, . [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, DOI 10.17487/RFC6906, March 2013, . [RFC7230] 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, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, . 9.2. Informative References [HeeryAndPatel] Heery, R. and M. Patel, "Application Profiles: Mixing and Matching Metadata Schemas", 2000, . [RFC4452] Van de Sompel, H., Hammond, T., Neylon, E., and S. Weibel, "The "info" URI Scheme for Information Assets with Identifiers in Public Namespaces", RFC 4452, DOI 10.17487/RFC4452, April 2006, . Svensson, et al. Expires September 10, 2021 [Page 17] Internet-Draft Handling Profiled Representations March 2021 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010, . [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . [W3C.REC-shacl-20170720] Knublauch, H. and D. Kontokostas, "Shapes Constraint Language (SHACL)", World Wide Web Consortium Recommendation REC-shacl-20170720, July 2017, . [W3C.REC-xmlschema11-1-20120405] Gao, S., Sperberg-McQueen, M., Thompson, H., Mendelsohn, N., Beech, D., and M. Maloney, "W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures", World Wide Web Consortium Recommendation REC-xmlschema11-1-20120405, April 2012, . Authors' Addresses Lars G. Svensson Email: lars.svensson@web.de URI: https://orcid.org/0000-0002-8714-9718 Ruben Verborgh Ghent University - imec Sint-Pietersnieuwstraat 41 Ghent 9000 Belgium Phone: +32 9 331 49 10 Email: ruben.verborgh@ugent.be URI: https://ruben.verborgh.org/ Svensson, et al. Expires September 10, 2021 [Page 18] Internet-Draft Handling Profiled Representations March 2021 Herbert Van de Sompel Data Archiving and Networked Services Anna van Saksenlaan 51 The Hague 2593 HW Netherlands Email: herbert.van.de.sompel@dans.knaw.nl URI: https://orcid.org/0000-0002-0715-6126 Svensson, et al. Expires September 10, 2021 [Page 19]