We are spec-ing how to represent a set of links in stand-alone documents, not how to represent HTTP headers in stand-alone documents. As such, I respectfully feel that your suggestion is beyond the scope of what we want to achieve.

@hvdsomp apologies if that was offensive in some way. I'm mainly hunting for what this spec is aiming to provide relative to the other solutions already available.

For example, Figure 4 in the current draft expresses a response that could be stored separately and delivered (if desired) as an message/http response. If that example were just the Link header shown there, then it would be both a valid message/http and a valid application/linkset.

Anyhow. I'll try to spend some time reading the latest version of the introduction material to better understand the use cases and distinctness intended.

it allows to identify linksets, which message/http does not allow.

You mean when using content negotiation? The discovery of a rel="linkset" would seem to identify the target resource as a linkset (regardless of it's response type). However, I can see a need to differentiate between message/http and an application/linkset response perhaps.

for one, message/http only allows complete HTTP messages, so representing a single header field is not possible.

I believe this is a valid message/http document (but could be wrong):

HTTP/1.1 200 OK
Link: <http://authors.example.net/johndoe>
   ; rel="author"
   ; type="application/rdf+xml"
   ; anchor="http://example.org/resource1

However, I could see a need for a new media type if restricting even that additional status line was important. That said, it would be nice to inherit from existing code/plumbing that can already parse message/http format and extra links from them.

I'm likely barking up the wrong tree again though... 🌳🐕