Re: [urn] Finalizing items from IETF 83

"Martin J. Dürst" <duerst@it.aoyama.ac.jp> Fri, 29 June 2012 10:18 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 6E0A421F8734 for <urn@ietfa.amsl.com>; Fri, 29 Jun 2012 03:18:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.239
X-Spam-Level:
X-Spam-Status: No, score=-99.239 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_34=0.6, 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 Oak04YfQGZ+V for <urn@ietfa.amsl.com>; Fri, 29 Jun 2012 03:18:12 -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 874BD21F8735 for <urn@ietf.org>; Fri, 29 Jun 2012 03:18:12 -0700 (PDT)
Received: from scmse02.scbb.aoyama.ac.jp ([133.2.253.231]) by scintmta02.scbb.aoyama.ac.jp (secret/secret) with SMTP id q5TAHxsH025789 for <urn@ietf.org>; Fri, 29 Jun 2012 19:18:03 +0900
Received: from (unknown [133.2.206.133]) by scmse02.scbb.aoyama.ac.jp with smtp id 1370_1e49_b390990e_c1d3_11e1_af2c_001d096c5782; Fri, 29 Jun 2012 19:17:58 +0900
Received: from [IPv6:::1] ([133.2.210.1]:60501) by itmail.it.aoyama.ac.jp with [XMail 1.22 ESMTP Server] id <S15D974C> for <urn@ietf.org> from <duerst@it.aoyama.ac.jp>; Fri, 29 Jun 2012 19:18:02 +0900
Message-ID: <4FED80D0.5000205@it.aoyama.ac.jp>
Date: Fri, 29 Jun 2012 19:17:52 +0900
From: "\"Martin J. Dürst\"" <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: Juha Hakala <juha.hakala@helsinki.fi>
References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us> <4FEBF708.9030604@helsinki.fi> <24637769D123E644A105A0AF0E1F92EF246915EE@dnbf-ex1.AD.DDB.DE> <4FEC2B8C.4070604@gmx.de> <4FEC4595.1020609@helsinki.fi>
In-Reply-To: <4FEC4595.1020609@helsinki.fi>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Julian Reschke <julian.reschke@gmx.de>, "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Finalizing items from IETF 83
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: Fri, 29 Jun 2012 10:18:13 -0000

On 2012/06/28 20:52, Juha Hakala wrote:

> On 28.6.2012 13:01, Julian Reschke wrote:

>> Namespace specifications define the namespace-specific part; nothing
>> else. Fragment syntax and semantics are defined by RFC 3986.
>>
>> A spec *can* point out that the URN does not identify something from
>> which a payload + media type can be retrieved, in which fragment
>> identifiers are not applicable. But that's different from disallowing
>> them.
>
> OK. It should be possible to adjust the text in rfc2141bis to say that
> there are namespaces in which fragment usage is not applicable since the
> resources which can be identified within than namespace - say, textual
> works as abstract entities in URN:ISTC - will not have fragments in the
> RFC 3986 sense of the word.

Strictly speaking, that's not true. It's perfectly possible to imagine 
(and even to set up, although that will require quite a bit of 
coordination) to have an identifier for "Much Ado about Nothing" and 
have fragment identifiers e.g. for Act I, II, III, IV, and V. These may 
not work with all resolution systems, or all representations, but that's 
not a problem. If a fragment identifier cannot be resolved, we just get 
the whole work. The only problem is when a fragment identifier leads to 
obviously different pieces in different representations (e.g. Act I in 
an XML representation and Act V in a mobi representation,...).

All this isn't new for URNs, it's exactly the same as for 
content-negotiated HTTP resources (different languages, HTML vs. XML vs. 
SVG vs. JSON vs. RDF, just to name a few).


> As far as I am concerned, it does no harm if the namespace registration
> request confirms that it is possible to use fragment to augment the
> functionality of the URNs from that particular namespace. For instance,
> I asked a permission from the ISBN Registration Authority to use
> fragments in the URN:ISBN namespace. Since this point will be made in
> the namespace registration request the national ISBN agencies and other
> ISBN users do not need to ask if fragments are allowed.

Nobody should have to ask. If it works, you can use it. If you can't 
make it work, it's a bad idea.

> And while some
> examples could be given in the namespace registration request it is
> definitely up to the URI Generic Syntax and other relevant technical
> documents to provide the necessary details for each document format.

Yes indeed.

Regards,    Martin.