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

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Wed, 28 March 2012 04:51 UTC

Return-Path: <duerst@it.aoyama.ac.jp>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB40021F85CE for <urn@ietfa.amsl.com>; Tue, 27 Mar 2012 21:51:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.042
X-Spam-Level:
X-Spam-Status: No, score=-100.042 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edkPzwkf-D1O for <urn@ietfa.amsl.com>; Tue, 27 Mar 2012 21:51:21 -0700 (PDT)
Received: from scintmta02.scbb.aoyama.ac.jp (scintmta02.scbb.aoyama.ac.jp [133.2.253.34]) by ietfa.amsl.com (Postfix) with ESMTP id 11FB321F85C3 for <urn@ietf.org>; Tue, 27 Mar 2012 21:51:19 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q2S4p6wo025858 for <urn@ietf.org>; Wed, 28 Mar 2012 13:51:06 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 3771_8f03_a13942a0_7891_11e1_b9db_001d096c5782; Wed, 28 Mar 2012 13:51:05 +0900
Received: from [IPv6:::1] ([133.2.210.1]:35304) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15AF943> for <urn@ietf.org> from <duerst@it.aoyama.ac.jp>; Wed, 28 Mar 2012 13:51:11 +0900
Message-ID: <4F7298B7.2050808@it.aoyama.ac.jp>
Date: Wed, 28 Mar 2012 13:51:03 +0900
From: =?UTF-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= <duerst@it.aoyama.ac.jp>
Organization: Aoyama Gakuin University
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100722 Eudora/3.0.4
MIME-Version: 1.0
To: Leslie Daigle <leslie@thinkingcat.com>
References: <20120312010553.16681.34930.idtracker@ietfa.amsl.com> <4F6F16E0.70703@thinkingcat.com> <4F7019DC.5080703@it.aoyama.ac.jp> <4F71DF07.6020803@thinkingcat.com>
In-Reply-To: <4F71DF07.6020803@thinkingcat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: urn@ietf.org
Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Mar 2012 04:51:24 -0000

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.