Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt Mon, 26 March 2012 10:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 483BF21F84D9 for <>; Mon, 26 Mar 2012 03:52:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 86a8s3jQ1izH for <>; Mon, 26 Mar 2012 03:52:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 96E6021F84A1 for <>; Mon, 26 Mar 2012 03:52:30 -0700 (PDT)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id q2QAqRSB004217; Mon, 26 Mar 2012 13:52:27 +0300
Received: from ( []) by (Horde Framework) with HTTP; Mon, 26 Mar 2012 13:52:27 +0300
Message-ID: <>
Date: Mon, 26 Mar 2012 13:52:27 +0300
To: Leslie Daigle <>
References: <> <> <> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) 4.2.2
Subject: Re: [urn] Fragments Re: I-D Action: draft-ietf-urnbis-rfc2141bis-urn-02.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Mar 2012 10:52:35 -0000


Quoting "Leslie Daigle" <>:

> I'm just going to follow up 2 points for now:
>>> The issue with doing that with URNs is: they are designed to be
>>> flexible enough to support multiple types of response -- the URN does
>>> not designate a type.
>> URN in general does not, but there are identifier systems which do.
> But this is the general URN syntax.  So we should have a syntax that  
> supports the general URN, not other identifier systems.

I am not sure what you mean by the general URN. URN system consists of  
namespaces, which establish their own rules as regards what kind of  
resources they identify and how. There are technical requirements that  
must apply to all the namespaces, but many things must be left to the  
namespace level, use of fragment being one of them.

>>> For example, you might get a PDF back instead of HTML, and then your
>>> HTML #<fragment> will be pointless.
>> With URN:ISBN this would not happen, since a book published in PDF
>> format will have another ISBN than the book in HTML format (provided
>> that the publisher is using the ISBN system correctly).
> Your parenthetical remark is key:  historicaly experience suggests  
> that there is little reason to expect they will.  Just looking at  
> the number of ISBNs assigned to teddy bears in gift shops, for  
> example.

Any identifier system can be misused and alas, ISBN is no exception.  
More alarming than those teddy bears (which got an ISBN so that they  
could be entered into a sales system which required ISBNs) is the  
emerging trend that some publishers especially in the USA would prefer  
to give the same ISBN to all manifestations of a book. However, as a  
rule the ISBN system works well.

When writing rfc2141bis and namespace registrations we should build  
upon the identifier standards and established practices on how to  
apply them, and not on the possibility that someone does not know how  
to implement the standard (or makes a decision to deviate from it on  
>>> 1/ a very thorough review by URI experts to make sure it actually
>>> would hold water,
>> There was quite a lot of discussion on the list about this in the past.
>> The outcome of that discussion is reflected in the current drafts.
> I'm not sure that you caught that I said URI experts, there.  Not  
> the URNbis WG mailing list.

OK. Such review is of course welcome. And we need also feedback from  
some identifier communities who may benefit from the <fragment> use.

Best regards,