Here's my feedback, mainly editorial nits...:
Additionally, the following rules are included from [RFC3986]: URI
and URI-Reference; from [RFC6838]: type-name and subtype-name; from
[W3C.CR-css3-mediaqueries-20090915]: media_query_list; and from
[RFC5646]: Language-Tag.
That doesn't work, as "_" is not a legal ABNF character.
2. Links
In this specification, a link is a typed connection between two
resources, and is comprised of:
o A _link context_,
o a _link relation type_ (Section 2.1),
o a _link target_, and
o optionally, _target attributes_ (Section 2.2).
It might be good to add forward references for "link context" and "link
target" as well.
Finally, links are consumed by _link applications_. Generally, an
application will define the link relation type(s) it uses, along with
the serialisation(s) that they might occur within. For example, the
application "Web browsing" looks for the "stylesheet" link relation
type in the HTML link serialisation, whereas the application
"AtomPub" uses the "edit" and "edit-media" link relations.
Actually, one popular browser also looks for the stylesheet link
relation in the "Link" header field...
Relation types are not to be confused with media types [RFC6838];
Media types are defined in RFC 2046; RFC 6838 is mainly about media type
registrations.
they do not identify the format of the representation that results
when the link is dereferenced. Rather, they only describe how the
current context is related to another resource.
o *Reference*: Reference to the document that specifies the link
relation type, preferably including a URI that can be used to
retrieve a copy of the document. An indication of the relevant
section(s) MAY also be included, but is not required.
s/MAY/can/
Note that relation types can be registered by third parties
(including the Expert(s)), if the Expert(s) determine that an
unregistered relation type is widely deployed and not likely to be
registered in a timely manner.
maybe s/registered/registed otherwise/?
2.1.1.2. Registration Request Processing
Relation types are registered on the advice of a Designated Expert
(appointed by the IESG or their delegate), with a Specification
Required (using terminology from [RFC5226]).
s/[RFC5226]/Section 4.1 of [RFC5226]/
2.2. Target Attributes
This specification does not attempt to coordinate the name of target
attributes, their cardinality or use. Serialisations SHOULD
coordinate their target attributes to avoid conflicts in semantics or
syntax.
I'm not sure who's the audience for this SHOULD, and how to implement
it. For instance, shouldn't this spec do this for the header field
serialization?
3. Link Serialisation in HTTP Headers
s/Headers/Header fields/
This specification defines the link-params "rel", "anchor", "rev",
"hreflang", "media", "title", "title*", and "type"; see Section 3.2,
Section 3.3 and Section 3.4.
s/Section 3.2, Section 3.3 and Section 3.4/Sections 3.2, 3.3, and 3.4/
3.1. Link Target
Each link-value conveys one target IRI as a URI-Reference (after
conversion to one, if necessary; see [RFC3987], Section 3.1) inside
angle brackets ("<>"). If the URI-Reference is relative, parsers
MUST resolve it as per [RFC3986], Section 5. Note that any base IRI
from the message's content is not applied.
Maybe s/base IRI from the message's content/base IRI appearing inside
the message's content/
3.2. Link Context
By default, the context of a link conveyed in the Link header field
is identity of the representation it is associated with, as defined
in [RFC7231], Section 3.1.4.1, serialised as a URI.
Broken sentence: "is identity".
The ABNF for the "anchor" parameter's value is:
URI-Reference
s/URI-Reference/URI-Reference; Section 4.1 of [RFC3986]/
Note that depending on HTTP status code and response headers, the
link context might be "anonymous" (i.e., no link context is
available). For example, this is the case on a 404 response to a GET
request.
I understand this is identical in RFC 5988, but where does this actually
come from? It basically restricts use of anchor-less link header fields
2xx responses, right?
3.3. Relation Type
The ABNF for the "rel" and "rev" parameters' values is:
relation-type *( 1*SP relation-type )
where:
relation-type = reg-rel-type | ext-rel-type
Finally I can use this link https://www.youtube.com/watch?v=LbK-g8tKnoc
in LC feedback!
reg-rel-type = LOALPHA *( LOALPHA | DIGIT | "." | "-" )
ext-rel-type = URI
s/URI/URI; Section 3 of [RFC3986]/
Note that extension relation types are REQUIRED to be absolute URIs
in Link headers, and MUST be quoted if they contain a semicolon (";")
s/headers/header fields/
or comma (",") (as these characters are used as delimiters in the
header field itself).
There are more characters legal in URIs but illegal in token -- so maybe
phrasing it like this can cause confusion. Maybe "MUST be quoted when
they contain characters not allowed in tokens, such as ...."?
3.4.1. Serialisation-Defined Attributes
The ABNF for the "type" parameter's value is:
type-name "/" subtype-name
(maybe point to https://tools.ietf.org/html/rfc6838#section-4.2 here)
3.5. Link Header Field Examples
Maybe add an example for multiple Link header field instances in a
single message?
4.1. Link HTTP Header Field Registration
Header field: Link
Applicable protocol: http
Status: standard
Author/change controller:
IETF (iesg(_at_)ietf(_dot_)org)
Internet Engineering Task Force
Specification document(s):
[RFC&rfc.number;]
s/[RFC&rfc.number;]/this document/
4.2. Link Relation Type Registry
Each published document will be at a URL mutually agreed to by IANA
and the Expert(s), and IANA will set HTTP response headers on them as
(reasonably) requested by the Expert(s).
Wow. Does IANA know that we want to configure their web server?
5. Security Considerations
Link applications ought to consider the attack vectors opened by
automatically following, trusting, or otherwise using links gathered
from HTTP headers. In particular, Link header fields that use the
s/headers/header fields/
"anchor" parameter to associate a link's context with another
resource are to be treated with due caution.
The Link header field makes extensive use of IRIs and URIs. See
[RFC3987] for security considerations relating to IRIs. See
[RFC3986] for security considerations relating to URIs. See
[RFC7230] for security considerations relating to HTTP headers.
s/headers/header fields/
7.1. Normative References
[W3C.CR-css3-mediaqueries-20090915]
Lie, H., Celik, T., Glazman, D., and A. Kesteren, "Media
Queries", World Wide Web Consortium CR CR-css3-
mediaqueries-20090915, September 2009,
<http://www.w3.org/TR/2009/CR-css3-mediaqueries-20090915>.
Need to update to
<https://www.w3.org/TR/2012/REC-css3-mediaqueries-20120619/>.
[W3C.REC-html5-20141028]
Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
Navara, E., O'Connor, T., and S. Pfeiffer, "HTML5",
World Wide Web Consortium Recommendation REC-
html5-20141028, October 2014,
<http://www.w3.org/TR/2014/REC-html5-20141028>.
Broken escape in author name.
A.1. Link Serialisation in HTML
HTML5 ([W3C.REC-html5-20141028]) Section 4.8 defines modern HTML
"Section 4.8 of HTML5"
links. That document links to the Microformats Wiki as a registry;
over time, the IANA registry ought to mirror its contents, and
ideally eventually replace it (although that depends on the HTML
community).
Appendix B. Algorithm for Parsing Link Headers
Given a HTTP header field-value "field_value" as a string assuming
ASCII encoding, the following algorithm can be used to parse it into
the model described by this specification:
This part is a bit scary -- I don't know how to review it. It might be
better to have code in an actual programming language, and a set of
tests for it.
1. Let "links" be an empty list.
2. Create "link_strings" by splitting "field_value" on ","
characters, excepting "," characters within quoted strings as per
I have my doubts that people will be able to translate it into actually
correct code. To detect whether something is inside a quoted-string
essentially requires running a parser; the prose here suggests that this
is not necessary.
It also should mention that there might be multiple instances of
field_value.