Subject: [httpapi] Fwd: New Version Notification for draft-wilde-linkset-07.txt

From: Erik Wilde <[email-masked]>
Date: Tue, 20 Oct 2020 09:47:45 +0200

hello!

it's great to see this new working group picking up steam!

attached please find a draft that we have been working on for quite a 
while, and which is we believe in a stage that warrants publication as 
an RFC.

we've been told that this new working group would be a good fit, and 
that's definitely the case. but we also want to make sure to progress 
with this as quickly as possible, as we have some major implementation 
work (first and foremost the GS1 work listed in the draft) depending on 
that.

it would be great to move forward with this as soon as possible. please 
let us know what the next steps are to make this happen.

thanks a lot and cheers,

dret.

-------- Forwarded Message --------
Subject: New Version Notification for draft-wilde-linkset-07.txt
Date: Fri, 16 Oct 2020 08:03:10 -0700
From: [email-masked]
To: Erik Wilde <[email-masked]>, Herbert Van de Sompel 
<[email-masked]>

A new version of I-D, draft-wilde-linkset-07.txt
has been successfully submitted by Erik Wilde and posted to the
IETF repository.

Name:		draft-wilde-linkset
Revision:	07
Title:		Linkset: Media Types and a Link Relation Type for Link Sets
Document date:	2020-10-16
Group:		Individual Submission
Pages:		29
URL:            https://www.ietf.org/archive/id/draft-wilde-linkset-07.txt
Status:         https://datatracker.ietf.org/doc/draft-wilde-linkset/
Htmlized:       https://datatracker.ietf.org/doc/html/draft-wilde-linkset
Htmlized:       https://tools.ietf.org/html/draft-wilde-linkset-07
Diff:           https://www.ietf.org/rfcdiff?url2=draft-wilde-linkset-07

Abstract:
    This specification defines two document formats and respective media
    types for representing sets of links as stand-alone resources.  One
    format is JSON-based, the other aligned with the format for
    representing links in the HTTP "Link" header field.  This
    specification also introduces a link relation type to support
    discovery of sets of links.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

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

---

From: Austin Wright <[email-masked]>
Date: Tue, 20 Oct 2020 10:09:04 -0700

Quick question: How is the application/linkset media type different from the application/link-format media type in RFC 6690?

Would it make sense to cite this as prior art?

Thanks,

Austin.

> On Oct 20, 2020, at 00:47, Erik Wilde <[email-masked]> wrote:
> 
> hello!
> 
> attached please find a draft that we have been working on for quite a while, and which is we believe in a stage that warrants publication as an RFC.
> 
> we've been told that this new working group would be a good fit, and that's definitely the case. but we also want to make sure to progress with this as quickly as possible, as we have some major implementation work (first and foremost the GS1 work listed in the draft) depending on that.
> 
> it would be great to move forward with this as soon as possible. please let us know what the next steps are to make this happen.
> 
> thanks a lot and cheers,
> 
> dret.
> 
> 
> To: Erik Wilde <[email-masked]>, Herbert Van de Sompel <[email-masked]>
> 
> 
> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi

---

From: Herbert Van de Sompel <[email-masked]>
Date: Tue, 20 Oct 2020 19:53:01 +0200

> Quick question: How is the application/linkset media type different from the application/link-format media type in RFC 6690?

I have some experience with this issue because I ran into it when doing Memento RFC7089. For that RFC, we needed a media type that exactly aligned with the format of the content of the HTTP Link header. At first glance, it looked like application/link-format was going to be it. However, it turns out that the media type actually imposes a few extras on top of the  format of the content of the HTTP Link header that are specific to the CoRE perspective, eg this snippet from RFC6690:

The CoRE Link Format is equivalent to the [RFC5988] link format;
   however, the ABNF in the present specification is repeated with
   improvements to be compliant with [RFC5234] and includes new link
   parameters.  The link parameter "href" is reserved for use as a query
   parameter for filtering in this specification (see Section 4.1) and
   MUST NOT be defined as a link parameter.

I remember some interactions with the CoRE people aimed at removing those extras from the media type definition but that went nowhere. Because Memento’s core focus was the introduction of datetime negotiation, we decided not to bother with registering a media type that didn’t have this CoRE perspective. We just went with application/link-format, and, in our RFC, conveyed our own perspective. In hindsight, that probably wasn’t very cool but, at that time, it really wasn’t our core concern. Meanwhile, application/link-format is used as a MIME type for TimeMaps in all Memento compliant applications, which basically includes all public web archives. 

With the Linkset RFC we do want a media type that exactly aligns with the definition of the format for the content of the Link header, ie without the CoRE extras. That will, btw, also become valuable for Memento because it will allow getting rid of its own perspective on the application/link-format media type  ...

> Would it make sense to cite this as prior art?

In the sense of clarifying the distinction? That's an idea, indeed.

Greetings

Herbert