Re: [dxwg] use standard for profile identification (#45)

OK, here is a straw-man proposal for some text to refer to existing standards for identifying and signalling profiles in HTTP. @dret does this address your issue?

# Existing standards for transporting profile information in HTTP headers
## Using Accept/Content Type together with the profile parameter
The HTTP Accept and Content-Type header fields [RFC 7231](https://tools.ietf.org/html/rfc7231) allow a client to specify acceptable media types (`Accept`) and a server to indicate the media type of the payload (`Content-Type`). A media type registration can also specify an optional list of media type parameters. Some media type registrations (e. g. `application/ld+json`) have specified the use of a media type parameter named “profile” that could be used to signal the profile the payload of the message conforms to. Example:
```
GET /some/resource HTTP/1.1
Accept: text/turtle;q=0.9;profile="urn:example:profile-1",
  text/turtle;q=0.7;profile="urn:example:profile-2";

HTTP/1.1 200 OK
Content-Type: text/turtle;profile=<urn:example:profile-2>
```
During TPAC 2018 in Lyon, the DXWG had a longer discussion with the JSON-LD WG and [it was concluded](https://www.w3.org/2018/10/26-dxwg-minutes.html#x06) that the “profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the media-type, such as the [JSON-LD profiles](https://www.w3.org/TR/json-ld/#application-ld-json) "expanded" (`http://www.w3.org/ns/json-ld#expanded`) or “flattened” (`http://www.w3.org/ns/json-ld#flattened`). In order to signal the use of media-type-independent profiles, the http header fields `Accept-Profile` and `Content-Profile` are to be used.
## Using a Link-header with rel=”profile” (RFC 6906)
The HTTP Link header field [RFC 8288](https://tools.ietf.org/html/rfc8288) relates a web resource (Link Context) to a target resource (Link Target) by specifying the relation between the two resources. One of the relation types is “profile” as defined in [RFC 6906](https://tools.ietf.org/html/rfc6906). RFC 6906 defines a profile as “additional semantics that can be used to process a resource representation […] that do not alter the basic media type semantics,” and specifically states that “creators and users of profiles MAY define and manage them in a way that allows them to be used across media types,” so that the “profile” relation seems like a suitable way to transport information about acceptable profiles (request) and payload profile (response). Example:
```
HEAD /some/other/resource HTTP/1.1
Accept: text/turtle;q=0.9,application/rdf+xml;q=0.5
Link: <http://example.com/profile-1>; rel="profile"

HTTP/1.1 200 OK
Content-type: text/turtle
Link: <http://example.com/profile-1>; rel="profile"
```
There is, however, no possibility to convey quality information (q-values) using the “profile” relation.
## Using the Prefer/Preference-Applied header fields (RFC 7240)
The http `Prefer` and `Preference-Applied` header fields [RFC 7240](https://tools.ietf.org/html/rfc7240) can be used to convey information about profile preferences. A client could use the `Prefer` header to tell the server about its preference for a payload conforming to a specific profile. If the server sends a `Preference-Applied` header field in the response, the client will know that the preference was honoured. Example:
```
GET /some/resource HTTP/1.1
Accept: text/turtle
Prefer: profile=<urn:example:schema>

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile=<urn:example:schema>
```
This approach has two disadvantages. The first is - as with the "Link" header, that there is no possibility to work with q-values. The second one is that the only way for a server to state that it ignored the preference stated by the client is to omit sending a "Preference-Applied" header. For the client - however - it is not clear if the "Preference-Applied" header is absent because the server did not honour the preference, or if it is because the server did not understand the "Prefer" header in the first place. This could be solved by making it mandatory to send a "Link: rel=profile" header when answering to a request with a "Prefer: profile=''" header in it. That solution requires that a client evaluates two different headers in order to find a response to its request for a specific profile, which would make client implementation more complicated.

If the text is OK, we also need to decide which document it goes into. It could either go into `dc-prof-conneg` (possibly in "related work") or into the IETF document. @RubenVerborgh what do you think?

-- 
GitHub Notification of comment by larsgsvensson
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/45#issuecomment-468327805 using your GitHub account

Received on Thursday, 28 February 2019 15:59:34 UTC