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

[Herbert Van de Sompel <[e-mail]>]

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

On Sun, Dec 13, 2020 at 10:16 PM Erik Wilde <[e-mail]> wrote:

> hello rich.
>
> On 2020-12-10 08:05, Salz, Rich wrote:
> > 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. :)
>
> 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:[e-mail] |
>             | http://dret.net/netdret    |
>             | http://twitter.com/dret    |
>


-- 
==================
Herbert Van de Sompel
Chief Innovation Officer
DANS
[e-mail]
[phone]
https://hvdsomp.info
https://orcid.org/0000-0002-0715-6126