Subject: [apps-discuss] URI templates in Link header fields

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Aug 2016 10:42:02 +0200

Hi there.

RFC 5988, defining the HTTP Link header field, predates RFC 6570, 
defining URI templates.

In the meantime, I heard of a few cases where people were trying to use 
templates in Link header fields (an obvious thing to do), and came up 
with hacks to do so with the existing Link header field.

I'm tempted to work on a small spec that defines an experimental new 
header field, similar to Link but allowing templates.

Is anybody aware of existing code trying to use templates in Link header 
fields? If so, please report over here (or in doubt send private email).

Best regards, Julian

---

From: Erik Wilde <[email-masked]>
Date: Mon, 29 Aug 2016 08:30:45 -0700

hello julian

> header field, similar to Link but allowing templates.

@mnot has been working on collecting ideas for an update to RFC 5988 for 
a while now. maybe that's one more motivation to go forward with this? 
i'd certainly be willing to put in some time to get it off the ground.

https://github.com/mnot/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Arfc5988bis

> fields? If so, please report over here (or in doubt send private email).

this is not really code, but people want to use URI templates and there 
have been some efforts to provide a context that makes that more easy:

- @mnot's https://tools.ietf.org/html/draft-nottingham-link-hint

- my own https://tools.ietf.org/html/draft-wilde-link-desc

- part of the JSON home model: 
https://tools.ietf.org/html/draft-nottingham-json-home#section-3.1

if i recall correctly all of these have slightly different use cases and 
models, but (unsurprisingly) also a lot of overlap. it would be great to 
consolidate all of this so that tooling and implementations can rely on 
a robust spec.

cheers,

dret.

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

---

From: Julian Reschke <[email-masked]>
Date: Mon, 29 Aug 2016 18:35:22 +0200

> https://github.com/mnot/I-D/issues?q=is%3Aissue+is%3Aopen+label%3Arfc5988bis

Yep, I'm aware of that...

> consolidate all of this so that tooling and implementations can rely on

Agreed.

Thanks for the feedback, Julian

---

From: Graham Klyne <[email-masked]>
Date: Tue, 30 Aug 2016 13:33:49 +0100

Hi!

I've wanted something like this in the past, and I *thought* I had some code 
that accepted a template in a custom header field.  But on closer examination, I 
see that I passed a template in the body of a POST submission.

It's something I could see myself using if specified.

And +1 to Erik Wilde's comment: "it would be great to consolidate all of this so 
that tooling and implementations can rely on a robust spec".

#g
--

On 29/08/2016 09:42, Julian Reschke wrote:
> Hi there.
>
> RFC 5988, defining the HTTP Link header field, predates RFC 6570, defining URI
> templates.
>
> templates in Link header fields (an obvious thing to do), and came up with hacks
> to do so with the existing Link header field.
>
> I'm tempted to work on a small spec that defines an experimental new header
> field, similar to Link but allowing templates.
>
> Is anybody aware of existing code trying to use templates in Link header fields?
> If so, please report over here (or in doubt send private email).
>
> Best regards, Julian
>
> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 30 Aug 2016 09:41:21 +1000

See also:
  https://www.ietf.org/archive/id/draft-nottingham-link-template-01.txt

> On 30 Aug 2016, at 2:35 AM, Julian Reschke <[email-masked]> wrote:
> 

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

---

From: Sean Leonard <[email-masked]>
Date: Tue, 30 Aug 2016 10:41:26 -0700

Overall it's a good idea, so +1 to the effort (to add URI template 
support to HTTP Links).

I give +½ to the consolidation comment. It would be good to consolidate, 
but I do not know if consolidating to one spec would put excessive 
burdens on diverse implementations that only need selected features 
(i.e., to support all features). Lack of knowledge of this space, that's 
all.

Regards,

Sean

On 8/30/2016 5:33 AM, Graham Klyne wrote:
> Hi!
>
> I've wanted something like this in the past, and I *thought* I had 
> some code that accepted a template in a custom header field.  But on 
> closer examination, I see that I passed a template in the body of a 
> POST submission.
>
> And +1 to Erik Wilde's comment: "it would be great to consolidate all 
> of this so that tooling and implementations can rely on a robust spec".
>
> #g
> -- 
>
>
>> defining URI
>> with hacks
>> header