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?
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.
> 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.
> Link-Template: </books/{book_id}/author>;
rel="author" anchor="#{book_id}"
This needs to use DQUOTE instead of angle brackets.
> 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?
2.1 var-base
This mechanism assumes that all variables come from the same base. Is
that assumption justified? (Not sure myself)
4. IANA Considerations
I'd make that a proper list instead of artwork (yes, nitpicking here)
5. Normative References
[HTTP] should use RFC 9110.
Best regards, Julian
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
