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

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

On Oct 20, 2020, at 19:09, Austin Wright <[e-mail]> wrote:
> 
> 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

> Thanks,
> 
> Austin.
> 
>> On Oct 20, 2020, at 00:47, Erik Wilde <[e-mail]> wrote:
>> 
>> 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: [e-mail]
>> To: Erik Wilde <[e-mail]>, Herbert Van de Sompel <[e-mail]>
>> 
>> 
>> 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:[e-mail] |
>>          | http://dret.net/netdret    |
>>          | http://twitter.com/dret    |
>> 
>> -- 
>> httpapi mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/httpapi
>