Use `Accept-Profile` header instead of `JsonLdContext` ?

I came accross this article from Ruben Verborgh: https://ruben.verborgh.org/articles/fine-grained-content-negotiation/

It advocates for a new `Accept-Profile` header, which could be the reverse solution of the existing MIME-type/profile combination used in the ActivityStreams spec: https://rubenverborgh.github.io/SDSVoc-2016/#activity-streams

> Because Activity Streams 2.0 can be considered a restricted profile of JSON-LD, Implementations should consider the `application/ld+json; profile="https://www.w3.org/ns/activitystreams"` media type as being equivalent to `application/activity+json`.
> https://www.w3.org/TR/activitystreams-core/#media-type

There is a whole WG working on this notion of profile:
https://www.w3.org/TR/dx-prof-conneg/

> This is distinct from negotiating by Media Type or Language: a profile may specify the content of information returned, which may be a subset of the information the responding server has about the requested resource, and may be structured in a specific way to meet interoperability requirements of a community of practice.

The last part of the sentence is close to what would be required for JSON-LD context.

But I still struggle to understand what they mean by profile. I'm especially wondering if it could fit with custom contexts. The current `JsonLdContext` header accept JSON-stringified arrays or objects.

Start by reviewing the current JsonLdContext header behavior, then read the linked Accept-Profile and Activity Streams profile-negotiation references. The issue is done only when the project has a decided, documented approach to whether Accept-Profile supports or replaces custom JSON-LD contexts.

Written by the indexing model from the issue text.