Request Content Negotiation Style

[YoucTagh]

What do you think of the idea to add a new subsection reflecting the new CN style Request Content Negotiation introduced in RFC 9110? This is similar to HTTP Client hints and Vary/Allow used in the document.

Description of the CN style:

By sending an accept-profile header in a response, the server can influence the selection of an appropriate content for subsequent requests for a resource (i.e., to indicate a preferred profile for subsequent requests for that resource). An example of client/server interaction:

Client request example:

GET /document HTTP/1.1
Host: example.org
Accept: text/turtle, application/rdf+xml
Connection: close

Server response example:

HTTP/1.1 200 OK
Content-Type: text/turtle
Vary: Accept, Accept-Profile
Accept-Profile: "http://example.org/shapes/shape-1"
Content-Length: 8724
Connection: close
...

[RubenVerborgh]

That would be a different way of advertising then, which the Link headers already do?

[YoucTagh]

Quoting from the current draft:

The "Link" header indicates the profile of the returned representation but also points at two alternative representations, each of which conforms to another profile.

As I understand it, it does not have the semantics to convey a preference from a server to a client. On the other hand, the Accept-Profile, when sent in a response, indicates the server's preferred profiles in the subsequent requests.

[larsgsvensson]

As I understand it, it does not have the semantics to convey a preference from a server to a client. On the other hand, the Accept-Profile, when sent in a response, indicates the server's preferred profiles in the subsequent requests.

Would that preference be to indicate "these are the only profiles that work for this resource"? If not, why would a server want to indicate which profiles a client should ask for?

[hvdsomp]

That is my interpretation. Seems more realistic to me that a server lets a client know what it supports than a client asking a server for whichever profile. I wonder what the interpretation of @YoucTagh is.

[YoucTagh]

This is also my interpretation. I can add that if the server uses the same accept profile syntax, q-values could be used to indicate a preference for some profiles over others, a use case being that checking the conformance of a profile requires less computational power for the server.

[hvdsomp]

It just, very belatedly, occurred to me that this approach could be a way to get rid of the dependency on the formats attribute from Link Hints. Although my understanding is that Request Content Negotiation would be about a server indicating its preferred profiles, it seems to me it could also be used to advertise all available profiles, in the same way the current spec does with alternate links.

A drawback I see is that the content of Accept-Profile could become significantly large. With the Link header approach, there is a way to move links into a Linkset in case the header becomes too large. There's no such way out for Accept-Profile.

It also would be a very significant change ...