Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt

["Martin J. Dürst" <[e-mail]>]

Hello Leslie,

On 2012/03/28 0:38, Leslie Daigle wrote:

> On 3/26/12 3:25 AM, "Martin J. Dürst" wrote:

>> Could this be relaxed to "responses for which there is a commitment that
>> the fragments, if interpretable, are interpreted consistenly"? This
>> would not exclude media types where a fragment identifier doesn't make
>> sense, but would, if implemented diligently, produce consistency across
>> all those media types where fragment identifiers make sense.
>
> I'm really not sure what this means, in practice.

Okay. Assume as an example that the resource can be served as HTML, as 
SVG, and as PDF, and that the last one doesn't allow fragment 
identifiers (that could be wrong, now or in the future). Then what this 
would mean is that one and the same fragment identifier would identify 
one and the same thing (chapter, paragraph, figure, whatever) in both 
the HTML and the SVG version. It's definitely possible to make this 
work, although it's of course also possible to mess this up.


> And, I find myself wondering: what's the _specified_ behaviour when a
> fragment reference cannot be resolved (by the client)?

A fragment identifier identifies a secondary resource, so if that 
doesn't work, all we know about is the resource. I don't think there's a 
spec for this, but I'd assume that most clients would resolve to the 
resource and then give up. And 'give up' would usually place the user at 
the top of the document.


Actually, I think RFC 3986 is pretty close to what I'm suggesting (third 
paragraph of http://tools.ietf.org/html/rfc3986#section-3.5):

                                                             If the
    primary resource has multiple representations, as is often the case
    for resources whose representation is selected based on attributes of
    the retrieval request (a.k.a., content negotiation), then whatever is
    identified by the fragment should be consistent across all of those
    representations.  Each representation should either define the
    fragment so that it corresponds to the same secondary resource,
    regardless of how it is represented, or should leave the fragment
    undefined (i.e., not found).


So I think I agree with you the URN spec shouldn't mess around with 
fragment identifiers, and that individual URN namespaces also should not 
mess around with fragment identifiers. The only thing these specs may 
want to do is to point to RFC 3986.

Regards,    Martin.