Hi Nicolás,
Thanks for reviewing; responses inline.
On 17/07/2009, at 5:45 AM, Nicolás Alvarez wrote:
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.
That's an interesting question; although that requirement has been
discussed extensively, this aspect has not yet come up.
The intent was that it apply to the target, the reason being that the
relation type and media type are orthoganal (if the type of the
relation needs to be contrained for a particular application, it can
be done by that application, not in the definition of the relation
type itself).
I think it's equally applicable to the context (and this is already
alluded to in separate text about not specifying the context in the
relation type, although it doesn't mention the context's type
specifically).
All of that said, it's pretty clear that despite good practice and
separation of concerns, people are going to want to do this whether we
like it or not. Therefore, I'm inclined to loosen this requirement to
SHOULD NOT (or even degrade it to a non-normative recommendation
against) making extension (NOT registered) relation types format-
specific.
The benefit here is that doing this encourages application-specific
relation types to be defined as extensions, which is their nominated
purpose.
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 ":="
Ack.
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.
They're both parsing requirements; the syntax is unambiguous about
what's allowed when produced. However, I'll try to tweak the text to
make this more obvious.
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")
Ack.
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.
Thank very much for the feedback!
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf