Subject: Re: [httpapi] Fwd: New Version Notification for draft-nottingham-link-template-03.txt

From: Phil Archer <[email-masked]>
Date: Wed, 1 Sep 2021 08:26:11 +0000

Hi Mark,

This is very interesting. No promises but it looks like something we're likely to want to implement both in HTTP Headers and in Linksets. The use case is for things like product batch numbers and serial numbers in a GS1 Digital Link URI that, through templating, can be re-written in arbitrary API calls.

Phil

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 September 2021 06:37, httpapi wrote:
Hi all,

I've had this spec on the back burner for a *long* time, because I wanted to make sure it was actually useful to someone before progressing it.

I've heard from a few people that it would be useful for them in the real world, so I'd like the WG to consider adoption.

Any thoughts?

Cheers,

        Begin forwarded message:

        From: [email-masked] <mailto:[email-masked]>

        Subject: New Version Notification for draft-nottingham-link-template-03.txt

        Date: 1 September 2021 at 3:35:21 pm AEST

        To: "Mark Nottingham" <[email-masked] <mailto:[email-masked]> >

        A new version of I-D, draft-nottingham-link-template-03.txt
        has been successfully submitted by Mark Nottingham and posted to the
        IETF repository.

        Name: draft-nottingham-link-template
        Revision: 03
        Title: The Link-Template HTTP Header Field
        Document date: 2021-09-01
        Group: Individual Submission
        Pages: 5
        URL:            https://www.ietf.org/archive/id/draft-nottingham-link-template-03.txt
        Status:         https://datatracker.ietf.org/doc/draft-nottingham-link-template/
        Html:           https://www.ietf.org/archive/id/draft-nottingham-link-template-03.html
        Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-link-template
        Diff:           https://www.ietf.org/rfcdiff?url2=draft-nottingham-link-template-03

        Abstract:
          This specification defines the Link-Template HTTP header field,
          providing a means for describing the structure of a link between two
          resources, so that new links can be generated.

        The IETF Secretariat

--
Mark Nottingham   https://www.mnot.net/

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: Julian Reschke <[email-masked]>
Date: Wed, 1 Sep 2021 12:49:26 +0200

Am 01.09.2021 um 07:36 schrieb Mark Nottingham:
> Hi all,
>
> I've had this spec on the back burner for a *long* time, because I
> wanted to make sure it was actually useful to someone before progressing it.
>
> I've heard from a few people that it would be useful for them in the
> real world, so I'd like the WG to consider adoption.
>
> Any thoughts?
>
> Cheers,

Absolutely.

The tricky thing is not the syntax, but how to describe variables,
though - that's the same problem with URI templates in general; the
consumer needs to understand what the variables are and how to fill
them. That's fine when there's already some out-of-band knowledge.

var-base is interesting; it probably would be good to create an example
using it...

Best regards, Julian

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 01 Sep 2021 22:39:07 +1000

Why not use structured fields for this?  As far as I can see, that just means <> becomes "", but the practical benefits seem to outweigh a small cosmetic consistency.

(Like Julian, var-base seems ... challenging.  I found the description of it hard to follow, but it seemed like the order of resolving against base URIs was unexpected.)

On Wed, Sep 1, 2021, at 15:36, Mark Nottingham wrote:
> > *From: [email-masked]
> > *Subject: **New Version Notification for draft-nottingham-link-template-03.txt*
> > *Date: *1 September 2021 at 3:35:21 pm AEST
> > *To: *"Mark Nottingham" <[email-masked]>
> > 
> > 
> httpapi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/httpapi
>

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Sep 2021 09:24:04 +1000

> Why not use structured fields for this?  As far as I can see, that just means <> becomes "", but the practical benefits seem to outweigh a small cosmetic consistency.

Good q. I think it should definitely be considered. This is currently following the Link syntax because a) it was written before SF, and b) Someone who's familiar with Link is going to wonder why. I doubt (b) is good enough.

It does beg the question of whether there should be a SF variant of Link. See also <https://mnot.github.io/I-D/binary-structured-headers/#links>.

> (Like Julian, var-base seems ... challenging.  I found the description of it hard to follow, but it seemed like the order of resolving against base URIs was unexpected.)

Yeah, that's only half-baked; needs more thought (and as Julian points out, examples).

Cheers,

---

From: "Max Maton" <[email-masked]>
Date: Thu, 02 Sep 2021 02:49:53 +0200

Hi Mark,

It seems an interesting proposal, currently we use the Link header with an `templated="true"` property. I have a two questions:

 - Am I correct in assuming that the variables are defined by the media type documentation for the returned Content-Type?
 - If so, wouldn't it make sense to leave the var-base out of the specification, given that people defining media types are free to add parameters and are free to define rules about how to resolve the variables? 

Best regards,

Max Maton

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 2 Sep 2021 10:56:38 +1000

Hi Max,

I think that how variables are defined / operate is going to be one of the things we'll need to discuss. var-base is just an initial (and incomplete) stab at that.

Cheers,

> On 2 Sep 2021, at 10:49 am, Max Maton <[email-masked]> wrote:
> 
> Hi Mark,
> 
>>> From: [email-masked]
>>> To: "Mark Nottingham" <[email-masked]>
>>> 
>>>

---

From: Dan Foygel <[email-masked]>
Date: Wed, 1 Sep 2021 19:56:53 -0700

We are also currently using Link headers with a templated="true" property,
but running into a specific problem when the URI Template contains a "*"
character (which isn't permitted in URIs, and therefore not permitted in a
Link header).

A simple approach that supports the equivalent of the Link header for URI
Templates would be ideal for what we're building - so I'm very supportive
of Mark's draft, and would encourage adoption.

To echo what others mentioned about "var-base", I also found it a bit
confusing, and I'm not sure if it's truly needed.

Thanks,

-Dan

On Wed, Sep 1, 2021 at 5:57 PM Mark Nottingham <[email-masked]> wrote:

> Hi Max,
>
> I think that how variables are defined / operate is going to be one of the
> things we'll need to discuss. var-base is just an initial (and incomplete)
> stab at that.
>
> Cheers,
>
>
> > It seems an interesting proposal, currently we use the Link header with
> an `templated="true"` property. I have a two questions:
> >
> >  - Am I correct in assuming that the variables are defined by the media
> type documentation for the returned Content-Type?
> >  - If so, wouldn't it make sense to leave the var-base out of the
> specification, given that people defining media types are free to add
> parameters and are free to define rules about how to resolve the variables?
> >
> > Best regards,
> >
> > Max Maton
> >
> >
> >
> >>> URL:
> https://www.ietf.org/archive/id/draft-nottingham-link-template-03.txt
> >>> Status:
> https://datatracker.ietf.org/doc/draft-nottingham-link-template/
> >>> Html:
> https://www.ietf.org/archive/id/draft-nottingham-link-template-03.html
> >>> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-nottingham-link-template
> >>> Diff:
> https://www.ietf.org/rfcdiff?url2=draft-nottingham-link-template-03
> >>>
> >>> Abstract: