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... 🌳🐕

Apparently, CoAP has an application/link-format format which is very similar also:
https://tools.ietf.org/html/rfc6690#section-2

Might be good to have some comparison information in the spec, so devs can understand the distinctions and choose accordingly--which might help address #89 also.

I'd be interested in helping review a comparison, but my writing/creating cycles are needed elsewhere currently. Sorry that's likely less than what's needed...

Having any level of comparison, though, should help avoid the confusion/concerns raised in #89.

Well, I have a whole history with CoAP grabbing application/link-format and making it stand for something that is "inspired by" the format of the Link header but has some of their own sauce added to it. The thing is that for the Memento protocol (RFC7089), we wanted to use the Link header format for timemap documents. Timemaps list all temporal versions of a resource, their respective datetimes, etc. We were happy to learn that someone had already written an I-D in which the format was identified as application/link-format. Until we noticed the added sauce, that is. Our interactions with CoAP representatives, trying to convince them to keep the format generic went nowhere. Since the domains targeted by CoAP and Memento are very distinct, we ended up using application/link-format anyhow in Memento. But that's kind of not really by the book ...