I'm reading draft-nottingham-http-link-header-06 and I have a few comments, or
at least things I am confused about.
Section 4 says: "As such, relation types are not format-specific, and MUST NOT
specify a particular format or media type that they are to be used with."
Does this refer to the format or media type of the context or the target?
I think there are reasonable use cases for a relation type to specify what the
target format is supposed to be. For example, an application-specific
extension relation type to link http://example.com to an API endpoint
(whatever that means) could say the target must be (or should be)
application/x-example-format+xml. Or a relation type could say the target
must be a subtype of the image/ mime type.
In the ABNF in section 5, enc2231-string refers to extended-value in section 7
of RFC2231. However, "extended-value" isn't explicitly defined anywhere in
RFC. The strange thing is that it's *used* in other ABNF constructions of
RFC2231, like extended-parameter; but I don't see it in the left hand side of
any ":="
Below the ABNF in section 5, it says:
"If the URI-Reference is relative, it MUST be resolved as per [RFC3986],
Section 5."
Does this mean that if a client parsing a Link header finds a relative URI
reference, it MUST resolve it to an absolute URI; or does it mean a server
MUST resolve relative URIs to absolute URIs before sending the Link header to
a client?
I think it should be clarified what side (client or server) that MUST applies
to.
Same for "If the anchor parameter's value is a relative URI[...]" in the
paragraph that follows.
Editorial issue: the last line of page 5 (second paragraph after ABNF in
section 5) should be moved to the beginning of page 6 for better readability.
(this is known as an "orphan line")
Apologies in advance if any of these issues were raised already (I'm not on
the mailing list myself), or if I'm posting to the wrong list for this topic.
Since I'm not subscribed to the list (and I'm having technical problems to
access gmane.org), I'd appreciate if you Cc: me in any replies.
--
Nicolas
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf