On 2017-05-14 09:35, Mark Nottingham wrote:
Thanks for the feedback, Julian. I've incorporated into source; responses below where necessary.
...
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.
Context and target are explained directly below the list; they don't have their own sections in the generic model.
I was going to say: there are sub sections in Section 3 - but yes, they
are specific to the header field...
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...
True, but that's not specified behaviour, AIUI.
<https://www.w3.org/TR/html5/document-metadata.html#the-link-element>:
"HTTP Link: headers, if supported, must be assumed to come before any
links in the document, in the order that they were given in the HTTP
message. These headers are to be processed according to the rules given
in the relevant specifications. [HTTP] [WEBLINK]"
So this refers to RFC 5988, which delegates to the IANA registry, which
in turn points back to the HTML spec for the definition of the
"stylesheet" link relation.
To me this sounds like it is well-defined, just not required ("if
supported").
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/
That's hard to automate; I think we can fix that at the RFC editor stage.
(hard to automate with markdown? :-)
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!
Source:
https://github.com/mnot/I-D/issues/33#issuecomment-260825416
Do you have any further suggestions?
Just added to the issue:
- "_" is not legal in a production name
- use "/" instead of "|"
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?
We're talking about it. Data, metadata -- what's the difference?
Operationally?
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.
That's not current practice for the intended audience, and shipping code makes it more likely that it will be used as a "reference implementation." This is marked as explicitly non-normative, and the precedence is clear.
It has been reviewed (and improved) by others, FWIW. If we find problems, we do have errata.
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.
I reluctantly agree. I'll need to rework the algorithm to address this; please stand by.
The only way to properly split list supporting field values is to parse
them according to the grammar for the list items; I don't believe in the
existence of a shortcut that actually works correctly. Suggesting
otherwise IMHO will lead to broken implementations for certain edge cases.
It also should mention that there might be multiple instances of field_value.
The algorithm is for parsing a single field-value...
Yes, but should we tell the audience that they need to parse *all* field
values, and combine the result?
Best regards, Julian