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

I think we're saying the same thing here, but your text seems to rely upon the reader to understand that it's underspecified purposefully (the "syntax they don't grok"), whereas I'd like to surface that in the document.

I know it's a bit messy, but there *is* a concept of something that says "when you're using links for X, this is valid, this isn't." 

I.e., consumers don't just pick a number from /dev/random to determine whether or not they pay attention to links with anchor parameters; it's written down somewhere, based on what they're doing with the link. 

I hesitate to make this into a big deal, especially since we're so close (I think) to having this out the door, but letting clients make an arbitrary decision is horrible for interoperability. If I'm using a link header to tell a web browser where a stylesheet is, I should be able to expect that different implementations will behave the same way with regard to it.



On 26/02/2010, at 8:49 PM, Julian Reschke wrote:

> 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


--
Mark Nottingham     http://www.mnot.net/

Received on Sunday, 28 February 2010 11:22:41 UTC