Clarify HTTP expectations for requests for unavailable profiles or media types

[rob-metalinkage]

#5 suggests HTTP 300

If a URI is recognised, but the media type and/or profile requested is not available, then a 300 response (multiple choice) is consistent with the presence of Link Headers and contains more information than a 404.

The payload (e.g. an HTML page) need not be specified - machine readable information is available via Link headers, but an
HTML response SHOULD contain an informative message that the resource was recognised but the representation requested was not available and a link the the alternates representation.

[YoucTagh]

I see four different options, depending on the context:

200 OK: to be used when the server provides a default representation. This could be confusing for the client, so a link header must be used to indicate the profile that the default representation conforms to.
300 Multiple Choices: useful if the server wants the client to engage in a reactive content negotiation style.
404 Not Found: self-explanatory, it is a possible option but does not provide any additional information.
406 Not Acceptable: unavailable representation and the server does not provide a default one. This differs from 404, the client knows that the server new the client wanted to engage in CN by profile but no alternative satisfy the desired profiles. The server can use the Link header to suggest alternatives.

See sections 12 and 15 of the HTTP RFC.

[YoucTagh]

Because we are focusing on the proactive style of content negotiation in this document, I would expect this behaviour:

The request:

GET /resource/a HTTP/1.1
Accept: text/turtle;q=0.8, application/xml;q=0.5
Accept-Profile: <urn:example:profile:x>

If resource a does not exist, a 404 status code is used.
If resource a exists and has a representation that conforms to profile x, a 200 status code + Link to profile x + alternates + Vary are used.
If the resource a exists and it doesn't have a representation conforming to profile x, we have two cases:

• The server sends back a default representation that conforms to profile y. So a 200 status code + Link to profile y + alternates + Vary are used.
• The server is not willing to send a default representation. So a 406 status code + Link to alternates + Vary are used.

[rob-metalinkage]

What if a profile x exists for the resource, but the requested media-type is not available for that profile? Is that the 406 (because I think its always unsafe or unfriendly to return a media-type different from an explicit request)

[larsgsvensson]

We could list both cases in the document and mention the pros and cons.

[YoucTagh]

@rob-metalinkage, for me this is the last case:

• The server sends back a default representation that conforms to profile x and its media type is m. So a 200 status code + Link to profile y + alternates + type + Vary are used.
• The server is not willing to send a default representation. So a 406 status code + Link to alternates + Vary are used.

Also, as @larsgsvensson mentioned, we can list both cases with their respective pros and cons.

[larsgsvensson]

The current version of the I-D does not mention the use of 300 Multiple Choices.
When using proactive content negotiation, the server has two possibilities:

• Either the server replies either with 200 OK and the representation it deems best given the request headers.
• Or - if there is no representation that suits the request - the server can reply with 200 OK and a default representation, or with 406 Not Acceptable and no representation.
  In both cases, appropriate Link-Headers must be present in the response.

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 http://example.org/shapes/shape-4, which is not among the ones preferred by the user agent. The server also reveals the existence of a representation that conforms to profile http://example.org/shapes/shape-5. 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. (Cf. §4.1.1)

For reactive content negotiation, the client would send an HTTP HEAD request. The server would answer with 200 OK and a list of Link Headers each containing a formats link hint. The client would avaluate thos headers in order to find out which profiles and representations the server supports for the given resource.

Figure 10 shows a user agent issuing an 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.

(This resolves action 3 from the 2023-09-06 telecon

[rob-metalinkage]

Possible interpretation

If a HEAD request is made with a combination of profile and media type and other possible negotiaton dimensions - then the response should be the same as for a GET request, including codes, except that the body will be blank.

HTTP protocol states "headers SHOULD be equivalent" (check wording)

[YoucTagh]

As discussed in the meeting 24/01/2024, the proposed wording is:

As specified in [[RFC9110]], If the HEAD method is used in a request that specifies preferences in the profile, media type, or other negotiation dimension, then the response should be the same as for a GET method, including headers and status code, except that the body MUST be empty. It is important to note that headers, for which the value is determined only while generating the response content, MAY be omitted

[rob-metalinkage]

We still need proposed text section 7.3.2

RFC 9110 has two options

https://www.rfc-editor.org/rfc/rfc9110.html#status.300

The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (Section 12).

If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.

https://www.rfc-editor.org/rfc/rfc9110.html#status.406

The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 12.1), and the server is unwilling to supply a default representation.

The server SHOULD generate content containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 15.4.1.
"

[YoucTagh]

I propose to add one of the following paragraphs at the end of Section 7.3.2 Get Resource by Profile:

---

If none of the available representations match the request, the server can either respond with a 200 OK status code and a default representation, or with a 406 NOT ACCEPTABLE status code and an empty body. In both cases appropriate Link headers should be present in the response.

---

If none of the available representations match the request, the server MAY respond with a 200 OK status code and a default representation, or with a 406 NOT ACCEPTABLE status code and an empty body. In both cases appropriate Link headers SHOULD be present in the response.

[larsgsvensson]

I'd suggest a mixture...
If none of the available representations match the request, the server dan respond with either a 200 OK status code and a default representation, or with a 406 NOT ACCEPTABLE status code and an empty body. In both cases appropriate Link headers SHOULD be present in the response.