Value of `application/linkset` vs. existing `message/http`

[BigBlueHat]

Does the application/linkset format introduce new value over message/http documents?

I understand it constrains the contents to only Link headers, but I'm not sure of the value of that additional constraint (relative to leaving the door open to other headers).

Sort of related to conversations in #103, #117, and #89.

[hvdsomp]

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.

[BigBlueHat]

@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.

[dret]

On 2019-03-13 15:42, BigBlueHat wrote:

Does the |application/linkset| format introduce new value over |message/http| https://tools.ietf.org/html/rfc7230#section-8.3.1 documents?

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

I understand it constrains the contents to only |Link| headers, but I'm not sure of the value of that additional constraint (relative to leaving the door open to other headers).

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

[BigBlueHat]

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

[BigBlueHat]

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.

[dret]

On 2019-07-19 07:16, BigBlueHat wrote:

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

aaahhhhh, CoAP. it never fails to show up when it comes to duplicating existing standards, and then tweaking them in minor ways to make them incompatible. keeping the spirit of WAP alive!

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 https://github.com/dret/I-D/issues/89 also.

you're probably right. would you be interested in adding this? it seems like it's text-based but uses UTF-8, and that it also adds a couple of new link parameters. so in the end, even though it looks similar, it is a different model and encoding.

[BigBlueHat]

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.

[dret]

On 2019-07-23 13:30, BigBlueHat wrote:

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

well, it's simply what we're all struggling with. thanks for pointing it out, that's a useful thing in itself! (i remember seeing it a long time ago, but completely forgot about it...)

Having any level of comparison, though, should help avoid the confusion/concerns raised in #89 https://github.com/dret/I-D/issues/89.

maybe @hvdsomp can at least mention it in the brief edits he is planning for next week ;-). we can simply point to it and leave the comparison to the reader, and leave it at that for now.

[hvdsomp]

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

[dret]

done.