Subject: Re: [httpapi] linkset draft and CoRE

From: Phil Archer <[email-masked]>
Date: Tue, 1 Dec 2020 09:13:09 +0000

Thanks for the pointer to the CoRE format, which I admit I'd not seen before.

There's a significant difference in the starting point for CoRE and Linkset. The former is designed for constrained environments and all discovery is via a query to the server's well-known location. For Linkset, you query a known resource, such as a publication or a product, and discover related resources. There is much in common as they're both based on Web Linking, but the different starting points/use cases are reflected throughout the documents.

Depending how you look at it, Linkset defines 2 or 3 formats for sets of links. One follows Web Linking, the other is a JSON format (the third renders that JSON as JSON-LD). From our POV, it's that JSON/JSON-LD that's the more important one.

If I understand all this correctly, CoRE is based on Web Linking but uses its extension mechanism to add in features important for IoT. Linkset uses Web Linking out of the box - which means that those CoRE extensions can be added to a Linkset anyway if so desired. So maybe a reference from Linkset to CoRE is called for.

What's not covered in Linkset is the idea of querying/filtering a linkset. *That* might be an argument for not using the CoRE media type for Linkset, but I don't think I have a strong view either way.

As it happens, we do have something like querying a linkset in the GS1 work in that you can ask a GS1 conformant resolver for a given link relation and be redirected to it, but I don't advocate that within Linkset, the importance of which, for GS1, is that JSON format, which is itself extensible of course. Such a format is not part of CoRE as it doesn't meet the IoT need for compactness, but it is important for the use cases that brought us to Linkset in the first place.

Phil

P.S. in case of interest:

For a given identifier (such as the number encoded in a typical barcode, known as a GTIN), you can ask for a particular kind of target resource, identified by its link relation type. For this purpose, we shorten 'link relation type' to 'link type' so you can do this:

https://id.gs1.org/01/9506000134352?linkType=gs1:productSustainabilityInfo

Rather than returning a set of links, you'll be redirected to a target that has an @rel value of gs1:productSustainabilityInfo. With no value of 'linkType' you're redirected to a default destination. If you want the set of links, you ask for it https://id.gs1.org/01/9506000134352?linkType=linkset

Our implementation of Linkset is WIP. If you follow the previous link you'll see, for example, that at the time of writing, 'linkset' is written 'linkSet' and the @rel types aren't being properly processed so we're not quite there yet. But we're getting there.

Phil Archer
Director, Web Solutions, GS1
https://www.gs1.org

Meet GS1 Digital Link Developers at
https://groups.google.com/forum/#!forum/gs1-digital-link-developers

https://philarcher.org
+44 (0)7887 767755
@philarcher1
Skype: philarcher

On 01 December 2020 02:22, httpapi wrote:
hello all.

looking at @mnot's notes i realize that i still owe a response to alexey melnikov, who was asking about the CoRE link format as defined by
https://tools.ietf.org/html/rfc6690#section-2

we did look into it when this was brought up a while ago, and here's a comment by my co-author made when this issue was brought up:

https://github.com/dret/I-D/issues/120#issuecomment-516785695

the short version is: CoRE links have a different serialization than the header field, and CoRE adds additional parameters into the mix.

i hope this explains the differences that i did not recall when this was brought up during my presentation at the IETF 109 meeting.

thanks a lot and cheers,

dret.

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

--
httpapi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/httpapi

CONFIDENTIALITY / DISCLAIMER: The contents of this e-mail are  confidential and are not to be regarded as a contractual offer or acceptance from GS1 (registered in Belgium). 
If you are not the addressee, or if this has been copied or sent to you in error, you must not use data herein for any purpose, you must delete it, and should inform the sender. 
GS1 disclaims liability for accuracy or completeness, and opinions expressed are those of the author alone. 
GS1 may monitor communications. 
Third party rights acknowledged. 
(c) 2020.

---

From: Erik Wilde <[email-masked]>
Date: Thu, 10 Dec 2020 07:21:27 -0800

hello rich.

thanks for the clarification.

On 2020-11-30 17:37, Salz, Rich wrote:
> The formal description of the workflow is at https://www.rfc-editor.org/info/rfc2026
> 
> A call for adoption means that the WG members want to work on the document. New drafts are often presented at the IETF meetings (like we just had), and then we poll the room to see if there's interest. The official process is that everyone done virtual or at F2F meetings must be confirmed on the mailing list.  Per the minutes:
> 	Rate Limit Headers will be confirmed on the mailing list
> 	Deprecation header will be confirmed on the mailing list
> 	Linkset has concerns about duplication of efforts, but we'll discuss adoption on the mailing list

how is this discussion of the adoption initiated? we have two rather big 
use cases that would benefit a lot from making progress, so if possible 
i'd like to start with whatever the next step is going to be.

from my recollection there was only one question which was about 
clarifying the relationship with CoRE, and i think that has been 
addressed already. if there are any outstanding issues, i'd like to 
start discussing them now so that we can move forward to the next step.

thanks a lot and cheers,

dret.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 15:57:00 +0000

>    how is this discussion of the adoption initiated?

The chairs initiate it.  There's lots of flexibility about timing and such. Sometimes things fall through the cracks, so it never hurts to send a note to the chairs reminding them.   Consider me reminded :)

As a reminder to the group, a draft doesn't have to be "almost done" to be adopted. It just means that the WG wants to use it as a starting point. As Barry said at our 109 meeting, drafts often end up evolving very differently from what they started out as.

WG members can feel free to start any technical discussion on the list that they want.  Just be nice and start a new thread. :)