Re: anchor parameter - LC comment on draft-nottingham-http-link-header-07.txt

On 26.02.2010 05:44, Mark Nottingham wrote:
> What's<ref>  here? I still don't see where the decision is made... at worst, this makes it seem like consumers can make an arbitrary decision as to whether to process a link with an anchor.

<ref> would point to text that states how to resolve against the context 
IRI when present.

And yes, I think consumers can make an almost arbitrary decision about 
it -- either they ignore the syntax they don't grok, or they process it 
as specified (where there's really only a single way to process them).

> This is where I am now:
>
>    Links with the anchor parameter MUST be ignored by consuming implementations, unless their use is explicitly specified.

That doesn't work for me, as it makes it sound that somebody needs to do 
additional work to "specify" it. Who? And what? The only thing that 
needs to be said is that the anchor param modifies the context, and 
recipients are allowed to ignore it if the resolved context IRI differs 
from the original one.

So how about (adding more context):

"The anchor parameter overrides this with another URI, such as a 
fragment of this resource, or a third resource (i.e., when the anchor 
value is an absolute URI).  If the anchor parameter's value is a 
relative URI, parsers MUST resolve it as per [RFC3986], Section 5.  Note 
that any base URI from the body's content is not applied.

Note that the presence of the anchor parameter affects the context IRI. 
Thus, consumers either MUST ignore all links that include the anchor 
parameter, or process it according to its definition above. In the 
latter case, the resulting context IRI can identify an entirely 
different resource, in which case consumers can choose to ignore the link."

(We might have to tune the paragraph for the case where the context 
resource is anonymous, though)

 > ...

Best regards, Julian

Received on Friday, 26 February 2010 09:50:03 UTC