Re: [Last-Call] [httpapi] Last Call: <draft-ietf-httpapi-link-template-02.txt> (The Link-Template HTTP Header Field) to Proposed Standard

[Mark Nottingham <[e-mail]>]

Hi Julian,

> On 17 May 2023, at 1:22 pm, Julian Reschke <[e-mail]> wrote:
> 
> Hi there,
> 
> below some feedback... (and sorry for not paying attention earlier in WGLC).
> 
> 1. Introduction
> 
> > This specification defines a HTTP header field [HTTP] for conveying
> templates for links in the headers of a HTTP message. It is
> complimentary to the Link header field defined in Section 3 of
> [WEB-LINKING], which carries links directly.
> 
> Is use in a trailer completely implausible?

No, but Link is defined as a header, and there haven't been requests to make it available as a trailer. While we could allow both, it would require applications using Link to disambiguate whether it's supported in trailers in their particular case, and we know that many applications won't bother.


> 2. The Link-Template Header Field
> 
> > Link-Template: "/{username}"; rel="https://example.org/rel/user"
> 
> It took me a moment to realize that rel uses a URI, not a registered
> link relation. That's IMHO "advanced" use of link relations, so maybe
> not totally suitable for the first example.

Fair call; updated in source.


> > Parameters on a templated link have identical semantics to those of a
> Link header field. This includes (but is not limited to) the use of the
> "rel" parameter to convey the relation type, the "anchor" parameter to
> modify the context IRI, and so on. Parameter values MUST be Strings.
> 
> Why are parameters limited to strings; just for consistency with "Link"?
> Anyway, RFC 8288 defines "title*", and the "Display Strings" that we may
> or may not get in SFBIS could be used here. I would prefer to wait for
> the outcome of that discussion before proceeding here.

I tend to agree; let's see what happens. Note that display strings are not functionally equivalent to that encoding -- so we'll have to figure out whether that's important.


> > Link-Template: </books/{book_id}/author>;
>               rel="author" anchor="#{book_id}"
> 
> This needs to use DQUOTE instead of angle brackets.

Fixed.


> > Implementations MUST support all levels of template defined by
> [URI-TEMPLATE] in both the rel and anchor parameters.
> 
> In *rel*? So use an URI template for the actual link relation??? What's
> the use case for that?

Ah -- that's a typo; the intent was the link and the anchor, not rel. Fixed (and good catch).


> 2.1 var-base
> 
> This mechanism assumes that all variables come from the same base. Is
> that assumption justified? (Not sure myself)

Possibly not, but this is very anticipatory, so a simple mechanism seemed best.


> 4. IANA Considerations
> 
> I'd make that a proper list instead of artwork (yes, nitpicking here)

Sure.


> 5. Normative References
> 
> [HTTP] should use RFC 9110.

Done - we started working on this one a while back :)

Cheers and thanks for the review,


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