Subject: [httpapi] Should we adopt linkset media types and link relation?

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 16:05:17 +0000

At our meeting in IETF 109, we discussed
                https://www.ietf.org/archive/id/draft-wilde-linkset-07.txt

There was some discussion about overlap with other specifications, but also interest in adoption.  We said we’d have more discussion for issuing the call, so please use this thread (or start others) to have that discussion. In particular, if there are concerns about adopting the document, please speak up. This is an ongoing discussion, probably not going to be resolved in what remains of this month/year. :)

---

From: Erik Wilde <[email-masked]>
Date: Sun, 13 Dec 2020 13:16:19 -0800

hello rich.

On 2020-12-10 08:05, Salz, Rich wrote:
> There was some discussion about overlap with other specifications, but 
> also interest in adoption.  We said we’d have more discussion for 
> issuing the call, so please use this thread (or start others) to have 
> that discussion. In particular, if there are concerns about adopting the 
> document, please speak up. This is an ongoing discussion, probably not 
> going to be resolved in what remains of this month/year. :)

again, i am (of course) in favor of adopting this draft. the one issue 
that was raised in the meeting at IETF 109 was the existence of the CoRE 
linking model and how it relates to the linkset model proposed in our draft.

herbert van de sompel and myself have discussed this issue, and we'll 
get back to this list with a brief explanation of how these two models 
compare, and why we felt that CoRE did not meet our needs. we hope that 
this explanation will resolve the open issue about the linkset draft.

thanks and cheers,

dret.

-- 
erik wilde | mailto:[email-masked] |
            | http://dret.net/netdret    |
            | http://twitter.com/dret    |

---

From: Herbert Van de Sompel <[email-masked]>
Date: Tue, 15 Dec 2020 08:54:59 +0100

Dear Rich, all,

Following up on Erik's mail, here's an analysis of the issue regarding the
perceived overlap between the linkset I-D and the CoRE RFC6690:

In section 4.1 <
https://datatracker.ietf.org/doc/html/draft-wilde-linkset-07#section-4.1>,
the Link Set I-D:
* Defines a serialization for documents that convey a set of links.
* Defines the application/linkset media type for this serialization.
* The defined serialization 100% matches the payload of the HTTP Link
header as defined in section 3 of RFC8288 <
https://datatracker.ietf.org/doc/html/rfc8288#section-3>.

In section 2 <https://tools.ietf.org/html/rfc6690#section-2>, RFC6690:
* Defines a serialization for documents that convey a set of links.
* Defines the application/link-format media type for this serialization.
* The serialization is equivalent (sic) to the payload of the HTTP Link
header as defined in section 3 of RFC8288 <
https://datatracker.ietf.org/doc/html/rfc8288#section-3>. It differs from
it in that:
- The encoding is UTF-8. It is not dependent on RFC2616 for its encoding.
- It defines new target attributes rt, it, sz that are not defined in
RFC8288. As such, these cannot be used as extension target attributes when
using the application/link-format media type.
- It reserves the href target attribute because it is used as a query
parameter for a filtering approach defined in the section 4.1 <
https://tools.ietf.org/html/rfc6690#section-4.1> of the RFC. As such, the
href target attribute can not be used as an extension target attribute when
using the application/link-format media type.

The definition of target attributes in RFC6690 that are not defined in
RFC8288 turns the CoRE application/link-format serialization into a
community profile of the generic model specified by Web Linking. In
contrast, the application/linkset serialization of the Link Set I-D fully
matches that generic model. That also holds for the
application/linkset+json serialization defined in the Link Set I-D.

I hope this clarifies the issue that was discussed in the recent WG
meeting. And, like Erik, I hope the I-D can be adopted.

Greetings

Herbert Van de Sompel

-- 
==================
Herbert Van de Sompel
Chief Innovation Officer
DANS
[email-masked]
+31 6 22 83 93 15
https://hvdsomp.info
https://orcid.org/0000-0002-0715-6126