Re: Last Call: draft-nottingham-http-link-header (Web Linking) to Proposed Standard

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/

Received on Friday, 17 July 2009 00:16:08 UTC