From juha.hakala@helsinki.fi  Wed Aug  3 23:11:04 2011
Return-Path: <juha.hakala@helsinki.fi>
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 91F9321F86D8 for <urn@ietfa.amsl.com>; Wed,  3 Aug 2011 23:11:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvmnpQM3gs8B for <urn@ietfa.amsl.com>; Wed,  3 Aug 2011 23:11:04 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id A82D321F867F for <urn@ietf.org>; Wed,  3 Aug 2011 23:11:02 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p746BBIZ019230 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 09:11:13 +0300
Message-ID: <4E3A37FE.7060609@helsinki.fi>
Date: Thu, 04 Aug 2011 09:11:10 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 06:11:04 -0000

Hello all,

I am revising the URN namespace registrations for ISBN and NBN (RFC 
3187bis and 3188bis). One of the issues that must be dealt with is the 
use of URI <fragment>.

On the basis of the discussion we had in the URNWG meeting during IETF 
80, I have assumed that <fragment> feature can be used, but only if RFC 
3986 requirements are taken into account. This must be made clear in 
RFC2141bis, and specified further in namespace registrations. There will 
be URN namespaces where <fragment> must not be used because the 
identifier system does not allow it.

ISBN and NBN (national bibliography number) are in different camps as 
regards URI fragments; the former does not allow them, but the latter 
does. Below are the relevant sections from the new Internet drafts. They 
are complementary in the sense that NBN can be used to identify 
component parts of a book (if they do not have ISBNs of their own). 
Armed with both specifications, national libraries and other users can 
assign identifiers to books and their logical / physical components, to 
the level of specificity desired.

This is what the revised RFC 3187bis says at the moment:

Books are finite objects, which may consist of component parts such as 
chapters or short stories / novellas. Such component parts may in some 
circumstances be given their own ISBNs. If they are not identified, ISBN 
standard does not allow augmentation of the ISBN of the book with URI 
fragments for identification of the component parts. Technically it is 
possible to add URI fragments to ISBN, but the resulting identifier will 
not be an ISBN; it could be a national bibliography number (URN:NBN) or 
an internal, completely non-standard identifier.

This is the corresponding section from RFC3188bis:

Bibliographic objects are finite, and may consist of component parts. If 
the object is a book, these component parts may be articles, chapters,
short stories / novellas, images and so on. When a bibliographic object 
such as a book is published in electronic form, it may be possible to 
access its component parts directly. If so, a reliable access key is 
needed. NBNs may be assigned to these component parts, depending the 
local NBN assignment policy. In some circumstances (if the stipulations 
of RFC 3986 and RFC2141bis are met), URI fragments can be applied in the 
NBN string.

However, since logical components of a book may not represented as URI 
fragments (and vice versa), component parts will normally be identified 
by using a local method not based on URI Generic syntax. This RFC will 
not specify the NBN method for generating fragment identifiers, since 
some organizations may use any available mechanism for other purposes. 
However, several viable methods can be suggested. For instance, the book 
as a whole may have an ISBN, and the NBNs for the component parts can be
based on the ISBN. Likewise there may be a base-NBN for the resource 
itself, and extended versions for the logical components. The most 
common approach may be the simplest: assign a separate NBN for each
component part.

------------

My aim is that the new versions of 3187bis and 3188bis will be published 
in August.

Best regards,

Juha
-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From julian.reschke@gmx.de  Thu Aug  4 00:31:28 2011
Return-Path: <julian.reschke@gmx.de>
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 ABA7821F8B68 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 00:31:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.214
X-Spam-Level: 
X-Spam-Status: No, score=-104.214 tagged_above=-999 required=5 tests=[AWL=-1.615, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7m25kOmXiBM4 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 00:31:27 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 5D21921F8B66 for <urn@ietf.org>; Thu,  4 Aug 2011 00:31:27 -0700 (PDT)
Received: (qmail invoked by alias); 04 Aug 2011 07:24:58 -0000
Received: from p508FD5FC.dip.t-dialin.net (EHLO [192.168.178.36]) [80.143.213.252] by mail.gmx.net (mp021) with SMTP; 04 Aug 2011 09:24:58 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18uuRomMVEujXbBj78UaBtLprMMkFPdY6ZEUz++aY gE1eTsGsSGjHUO
Message-ID: <4E3A4947.1070209@gmx.de>
Date: Thu, 04 Aug 2011 09:24:55 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi>
In-Reply-To: <4E3A37FE.7060609@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 07:31:28 -0000

On 2011-08-04 08:11, Juha Hakala wrote:
> Hello all,
>
> I am revising the URN namespace registrations for ISBN and NBN (RFC
> 3187bis and 3188bis). One of the issues that must be dealt with is the
> use of URI <fragment>.
>
> On the basis of the discussion we had in the URNWG meeting during IETF
> 80, I have assumed that <fragment> feature can be used, but only if RFC
> 3986 requirements are taken into account. This must be made clear in
> RFC2141bis, and specified further in namespace registrations. There will
> be URN namespaces where <fragment> must not be used because the
> identifier system does not allow it.
> ...

Clarifying: the RFC 3986 requirement is:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications." -- 
<http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

Best regards, Julian

From evnikita2@gmail.com  Thu Aug  4 01:42:17 2011
Return-Path: <evnikita2@gmail.com>
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 B668E21F8BBC for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 01:42:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.452
X-Spam-Level: 
X-Spam-Status: No, score=-3.452 tagged_above=-999 required=5 tests=[AWL=0.147,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1f7FtaYoFNLr for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 01:42:17 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B09FB21F8BBA for <urn@ietf.org>; Thu,  4 Aug 2011 01:42:16 -0700 (PDT)
Received: by fxe6 with SMTP id 6so2024509fxe.31 for <urn@ietf.org>; Thu, 04 Aug 2011 01:42:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=9wHsY4dP4iPI+sxQeOjb8ffixa8/qa/7nIc5pPT8P00=; b=HztZbwsrZyka5FgF9Lv5s9v6ViWOFNsAgGhmlCOAXlSiAj+cl5F8teMv+yOG96tgMz xqB1wCAzeeF8LKcDTJrDNtrNKw4ZnUnfqSiZ4fruNxEHilCOLonREAQt4rjSzbsv+Rup kNQKPvNwIi6Te+9BcujJlVZs8YBgsTsvBeSok=
Received: by 10.204.138.200 with SMTP id b8mr183469bku.45.1312447350175; Thu, 04 Aug 2011 01:42:30 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id l21sm466764bkt.2.2011.08.04.01.42.27 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 01:42:29 -0700 (PDT)
Message-ID: <4E3A5B9A.9060908@gmail.com>
Date: Thu, 04 Aug 2011 11:43:06 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: urn@ietf.org
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de>
In-Reply-To: <4E3A4947.1070209@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 08:42:17 -0000

04.08.2011 10:24, Julian Reschke wrote:
> On 2011-08-04 08:11, Juha Hakala wrote:
>> Hello all,
>>
>> I am revising the URN namespace registrations for ISBN and NBN (RFC
>> 3187bis and 3188bis). One of the issues that must be dealt with is the
>> use of URI <fragment>.
>>
>> On the basis of the discussion we had in the URNWG meeting during IETF
>> 80, I have assumed that <fragment> feature can be used, but only if RFC
>> 3986 requirements are taken into account. This must be made clear in
>> RFC2141bis, and specified further in namespace registrations. There will
>> be URN namespaces where <fragment> must not be used because the
>> identifier system does not allow it.
>> ...
>
> Clarifying: the RFC 3986 requirement is:
>
> "The semantics of a fragment identifier are defined by the set of 
> representations that might result from a retrieval action on the 
> primary resource. The fragment's format and resolution is therefore 
> dependent on the media type [RFC2046] of a potentially retrieved 
> representation, even though such a retrieval is only performed if the 
> URI is dereferenced. If no such representation exists, then the 
> semantics of the fragment are considered unknown and are effectively 
> unconstrained. Fragment identifier semantics are independent of the 
> URI scheme and thus cannot be redefined by scheme specifications." -- 
> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

... Correspondingly, it is only possible to use the fragment identifier 
when the URI/IRI is clear about the media type of the resource it refers 
to.  This may be determined from the URI itself or if it is mandatory 
that the particular type of a resource identifier must be resolved to 
the resource of a particular type.  URN with ISBN may refer to the text 
of a book in .txt, .html, .doc, .pdf, .ps, format or worse; URN with 
ISBN may refer to the page with book's annotation in any of the above 
format; or something else.  It is impossible to know for sure that "this 
URN is resolved to <bla-bla-bla> format", and, correspondingly, use 
fragment identifiers.  Here I agree with Juha.

With respect to NBNs.  The situation is the same.  The matter of 
fragment ID is the type, the format of the resource, not its actual 
contents.  The same publication with the unique NBN number may exist in 
electronic form in different formats.  Just the same as above.

So, my position is that defining the fragment ID for use with ISBN and 
NBN URNs makes very little sense; they may only be useful in URNs which 
have very limited scope and resolve to the resource of the type which is 
predefined.

(BTW: Fragment IDs, per RFC 3986, are allowed to be present in any URI, 
including URN; however, they cannot be effectively handled in the latter 
case.  I think RFC 2141bis should be clear that this part of an URI, if 
present, should be ignored).

(BTW2: Is new revision of 2141bis going to be published soon?)

Mykyta Yevstifeyev

>
> Best regards, Julian
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>


From juha.hakala@helsinki.fi  Thu Aug  4 03:55:47 2011
Return-Path: <juha.hakala@helsinki.fi>
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 E1A4221F8B2E for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 03:55:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.699
X-Spam-Level: 
X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHbbrpl1GDoy for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 03:55:46 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9172921F8B26 for <urn@ietf.org>; Thu,  4 Aug 2011 03:55:44 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p74Ats1G002348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 13:55:55 +0300
Message-ID: <4E3A7ABA.7060500@helsinki.fi>
Date: Thu, 04 Aug 2011 13:55:54 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com>
In-Reply-To: <4E3A5B9A.9060908@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 10:55:48 -0000

Privyet Mykyta; Hello all,

Some comments below.

Mykyta Yevstifeyev wrote:

>> Clarifying: the RFC 3986 requirement is:
>>
>> "The semantics of a fragment identifier are defined by the set of 
>> representations that might result from a retrieval action on the 
>> primary resource. The fragment's format and resolution is therefore 
>> dependent on the media type [RFC2046] of a potentially retrieved 
>> representation, even though such a retrieval is only performed if the 
>> URI is dereferenced. If no such representation exists, then the 
>> semantics of the fragment are considered unknown and are effectively 
>> unconstrained. Fragment identifier semantics are independent of the 
>> URI scheme and thus cannot be redefined by scheme specifications." -- 
>> <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>

I have added a reference to media type and RFC 2046 into the draft.
> 
> ... Correspondingly, it is only possible to use the fragment identifier 
> when the URI/IRI is clear about the media type of the resource it refers 
> to.  This may be determined from the URI itself or if it is mandatory 
> that the particular type of a resource identifier must be resolved to 
> the resource of a particular type.  URN with ISBN may refer to the text 
> of a book in .txt, .html, .doc, .pdf, .ps, format or worse; URN with 
> ISBN may refer to the page with book's annotation in any of the above 
> format; or something else.  It is impossible to know for sure that "this 
> URN is resolved to <bla-bla-bla> format", and, correspondingly, use 
> fragment identifiers.  Here I agree with Juha.

I disagree with Mykyta (but hopefully not with myself :-)).

The reason why URN:ISBN namespace does not allow fragments has to do 
with ISBN syntax. This is OK:

http://urn.fi/URN:ISBN:978-952-10-7060-0

but I am not allowed to add anything to the namespace specific string 
even if the media type in which this book is published would allow that. 
Of course, adding <query> would be OK since it would not be part of the 
identifier.

The URN:ISBN string itself does not imply any media type directly, but 
ISBN assignment rules make it clear that if the media type changes, a 
new ISBN must be assigned. The ISBN above belongs to a PDF version to a 
dissertation; if it is migrated to EPUB 3, a new ISBN is required.
> 
> With respect to NBNs.  The situation is the same.  The matter of 
> fragment ID is the type, the format of the resource, not its actual 
> contents.  The same publication with the unique NBN number may exist in 
> electronic form in different formats.  Just the same as above.

NBN does not refer to the work, but to a single manifestation of the 
work (in one file format). Manifestations in different file formats will 
get a different URN:NBNs. The reason for this is that file format 
changes may have an impact on the look and feel of the resource, and 
once something changes, for librarians it is no longer the same thing. 
We've had similar practices for printed stuff: hard back and paper back 
versions of a book have different ISBNs.

There is an interesting problem that all digital manifestations will be 
short-lived. When URN:ISBNs and URN:NBNs are not moved over to more 
modern versions of the document (which will receive other URNs) then 
somehow we must guarantee that the users will be made aware that there 
are later versions available as well.

Other URN namespaces may be more flexible than the ones we are dealing 
now. We could have for instance urn:mykyta where the rule is that the 
file format does not matter. I don't know how much we can /should do in 
RFCs to co-ordinate those namespaces that deal with digital 
manifestations. Works are of course a different matter altogether, since 
they are immaterial and as such persistent.

Independently of any physical manifestations libraries will also 
describe and identify works, but then we do not use ISBN but ISTC 
(International standard text code) for textual resources. And 
registering a namespace for that identifier (which has just recently 
went into production) remains to be done.

> So, my position is that defining the fragment ID for use with ISBN and 
> NBN URNs makes very little sense; they may only be useful in URNs which 
> have very limited scope and resolve to the resource of the type which is 
> predefined.

My take on this is that if we have e.g. a book in a file format that 
allows specification of fragments, then it is possible that these 
fragments can be accessed directly using HTTP URIs, and improving 
persistence of these access points to with URNs may make sense.

In case of multimedia documents (with a multitude of file formats), 
URN:NBNs must be assigned at the file format level if the intention is 
to use fragments in one or more of these formats.
> 
> (BTW: Fragment IDs, per RFC 3986, are allowed to be present in any URI, 
> including URN; however, they cannot be effectively handled in the latter 
> case.  I think RFC 2141bis should be clear that this part of an URI, if 
> present, should be ignored).
> 
> (BTW2: Is new revision of 2141bis going to be published soon?)

Alfred Hoenes indicated before his summer vacation that he plans to 
concentrate on URNBIS work during the first half of August.

Best regards,

Juha
> 
> Mykyta Yevstifeyev
> 
>>
>> Best regards, Julian
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>>
> 
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From julian.reschke@gmx.de  Thu Aug  4 04:17:50 2011
Return-Path: <julian.reschke@gmx.de>
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 7944E21F8A4E for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.614
X-Spam-Level: 
X-Spam-Status: No, score=-104.614 tagged_above=-999 required=5 tests=[AWL=-2.615, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PQBiI2kK8EHB for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:17:50 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 71AE621F86BB for <urn@ietf.org>; Thu,  4 Aug 2011 04:17:49 -0700 (PDT)
Received: (qmail invoked by alias); 04 Aug 2011 11:18:00 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp048) with SMTP; 04 Aug 2011 13:18:00 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX1+WcB515/aWYBLnXla6WUowy9UFknlbpTbpPZHP31 hQ6dFkmIfxK8OH
Message-ID: <4E3A7FE3.8090301@gmx.de>
Date: Thu, 04 Aug 2011 13:17:55 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi>
In-Reply-To: <4E3A7ABA.7060500@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 11:17:50 -0000

On 2011-08-04 12:55, Juha Hakala wrote:
> ...
> I disagree with Mykyta (but hopefully not with myself :-)).
>
> The reason why URN:ISBN namespace does not allow fragments has to do
> with ISBN syntax. This is OK:
>
> http://urn.fi/URN:ISBN:978-952-10-7060-0
>
> but I am not allowed to add anything to the namespace specific string
> even if the media type in which this book is published would allow that.
> Of course, adding <query> would be OK since it would not be part of the
> identifier.
 > ...

I don't believe an URI scheme (and thereby an URN namespace) can make 
this restriction.

> The URN:ISBN string itself does not imply any media type directly, but
> ISBN assignment rules make it clear that if the media type changes, a
> new ISBN must be assigned. The ISBN above belongs to a PDF version to a
> dissertation; if it is migrated to EPUB 3, a new ISBN is required.

If the ISBN above is guaranteed to identify a PDF document then I don't 
see why using a PDF anchor shouldn't work.

 > ...

Best regards, Julian

From juha.hakala@helsinki.fi  Thu Aug  4 04:46:48 2011
Return-Path: <juha.hakala@helsinki.fi>
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 01BC321F8B6E for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:46:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.849
X-Spam-Level: 
X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150,  BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OWaJyWABADrq for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:46:47 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5AFF921F8B6A for <urn@ietf.org>; Thu,  4 Aug 2011 04:46:45 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p74BksCD023412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 4 Aug 2011 14:46:55 +0300
Message-ID: <4E3A86AE.60000@helsinki.fi>
Date: Thu, 04 Aug 2011 14:46:54 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3A7FE3.8090301@gmx.de>
In-Reply-To: <4E3A7FE3.8090301@gmx.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 11:46:48 -0000

Hello,

Julian Reschke wrote:

>> but I am not allowed to add anything to the namespace specific string
>> even if the media type in which this book is published would allow that.
>> Of course, adding <query> would be OK since it would not be part of the
>> identifier.
>  > ...
> 
> I don't believe an URI scheme (and thereby an URN namespace) can make 
> this restriction.

ISBN can and must. If you add e.g. a fragment identifier to the end of 
the URN:ISBN string, the resulting identifier is not an ISBN anymore. Of 
course the new identifier can still be a valid URI and it may belong to 
some other URN namespace such as NBN.

>> The URN:ISBN string itself does not imply any media type directly, but
>> ISBN assignment rules make it clear that if the media type changes, a
>> new ISBN must be assigned. The ISBN above belongs to a PDF version to a
>> dissertation; if it is migrated to EPUB 3, a new ISBN is required.
> 
> If the ISBN above is guaranteed to identify a PDF document then I don't 
> see why using a PDF anchor shouldn't work.

An ISBN given to a PDF version of a book must not apply to any other 
version of that book, or to some other book.

Having said this, there are cases in some countries (which I do not wish 
to name here) where publishers insist upon giving the same ISBN to all 
e-versions of a book. In such a case, ISBN does not provide even a 
reliable starting point for creating an identifier for a fragment in one 
of these formats. Any standard is only as strong as the weakest link; in 
this case it is a subset of users who abuse the standard (and may come 
to regret it later on).

Juha
> 
>  > ...
> 
> Best regards, Julian
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From julian.reschke@gmx.de  Thu Aug  4 04:57:35 2011
Return-Path: <julian.reschke@gmx.de>
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 5649621F8B7B for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:57:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.539
X-Spam-Level: 
X-Spam-Status: No, score=-104.539 tagged_above=-999 required=5 tests=[AWL=-2.540, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-nmXUNmF1mF for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 04:57:34 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 52FB921F8AEA for <urn@ietf.org>; Thu,  4 Aug 2011 04:57:34 -0700 (PDT)
Received: (qmail invoked by alias); 04 Aug 2011 11:57:43 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp034) with SMTP; 04 Aug 2011 13:57:43 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18G31xEwo8Gc/Eh7hu44Zr+kopF5rVA7fNFLtQ/er PEqJhSfOzSf2sb
Message-ID: <4E3A8934.7040301@gmx.de>
Date: Thu, 04 Aug 2011 13:57:40 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3A7FE3.8090301@gmx.de> <4E3A86AE.60000@helsinki.fi>
In-Reply-To: <4E3A86AE.60000@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 11:57:35 -0000

On 2011-08-04 13:46, Juha Hakala wrote:
> Hello,
>
> Julian Reschke wrote:
>
>>> but I am not allowed to add anything to the namespace specific string
>>> even if the media type in which this book is published would allow that.
>>> Of course, adding <query> would be OK since it would not be part of the
>>> identifier.
>> > ...
>>
>> I don't believe an URI scheme (and thereby an URN namespace) can make
>> this restriction.
>
> ISBN can and must. If you add e.g. a fragment identifier to the end of
> the URN:ISBN string, the resulting identifier is not an ISBN anymore. Of
> course the new identifier can still be a valid URI and it may belong to
> some other URN namespace such as NBN.

A URN:ISBN URI is not an ISBN in the first place, so I think the above 
doesn't make any sense (sorry :-).

> ...

Best regards, Julian

From jehakala@mappi.helsinki.fi  Thu Aug  4 07:15:28 2011
Return-Path: <jehakala@mappi.helsinki.fi>
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 298FC21F8B47 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 07:15:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jjy0UyLNN2N2 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 07:15:27 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 61F6B21F8B39 for <urn@ietf.org>; Thu,  4 Aug 2011 07:15:25 -0700 (PDT)
Received: from webmail.helsinki.fi (webmail1-vallila2.fe.helsinki.fi [128.214.173.135]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p74EFY14014987; Thu, 4 Aug 2011 17:15:34 +0300
Received: from a88-113-47-109.elisa-laajakaista.fi (a88-113-47-109.elisa-laajakaista.fi [88.113.47.109]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 04 Aug 2011 17:15:34 +0300
Message-ID: <20110804171534.103213sel1007s06.jehakala@webmail.helsinki.fi>
Date: Thu, 04 Aug 2011 17:15:34 +0300
From: jehakala@mappi.helsinki.fi
To: "Julian Reschke" <julian.reschke@gmx.de>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3A7FE3.8090301@gmx.de> <4E3A86AE.60000@helsinki.fi> <4E3A8934.7040301@gmx.de>
In-Reply-To: <4E3A8934.7040301@gmx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.2.2
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 14:15:28 -0000

Hello Julian,

Quoting "Julian Reschke" <julian.reschke@gmx.de>:

> On 2011-08-04 13:46, Juha Hakala wrote:
>> Hello,
>>
>> Julian Reschke wrote:
X
> A URN:ISBN URI is not an ISBN in the first place, so I think the  
> above doesn't make any sense (sorry :-).
>
According to RFC 3187 (the namespace registration of the ISBN  
namespace), all the URN namespace specific strings in the ISBN  
namespace must be ISBNs. So every URN:ISBN URI must contain a valid  
ISBN.

If I construct something like

URN:ISBN:978-951-0

to identify the largest publisher in Finland the string is a valid URI  
but it is not a valid URN because it breaks the rules of the ISBN  
namespace. But I might do something like

URN:ISBNFINPUB:978-951-0

and nobody would object (provided that I am not breaking the  
regulations of the ISBNFINPUB namespace which must be registered  
before I can build a URN above).


All the best,

Juha

> Best regards, Julian
>
>




From julian.reschke@gmx.de  Thu Aug  4 07:48:03 2011
Return-Path: <julian.reschke@gmx.de>
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 DCEAF21F8AA8 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 07:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.41
X-Spam-Level: 
X-Spam-Status: No, score=-104.41 tagged_above=-999 required=5 tests=[AWL=-2.411, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAng74PPlAR5 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 07:48:03 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 04E6921F8A96 for <urn@ietf.org>; Thu,  4 Aug 2011 07:48:02 -0700 (PDT)
Received: (qmail invoked by alias); 04 Aug 2011 14:48:16 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp025) with SMTP; 04 Aug 2011 16:48:16 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX18SlaNBz64SlbVT62yST0l2WxsWtKIIQ8anw7LOQz 3K0oYsOZdkSdiK
Message-ID: <4E3AB12D.3010608@gmx.de>
Date: Thu, 04 Aug 2011 16:48:13 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: jehakala@mappi.helsinki.fi
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3A7FE3.8090301@gmx.de> <4E3A86AE.60000@helsinki.fi> <4E3A8934.7040301@gmx.de> <20110804171534.103213sel1007s06.jehakala@webmail.helsinki.fi>
In-Reply-To: <20110804171534.103213sel1007s06.jehakala@webmail.helsinki.fi>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 04 Aug 2011 14:48:04 -0000

On 2011-08-04 16:15, jehakala@mappi.helsinki.fi wrote:
> Hello Julian,
>
> Quoting "Julian Reschke" <julian.reschke@gmx.de>:
>
>> On 2011-08-04 13:46, Juha Hakala wrote:
>>> Hello,
>>>
>>> Julian Reschke wrote:
> X
>> A URN:ISBN URI is not an ISBN in the first place, so I think the above
>> doesn't make any sense (sorry :-).
>>
> According to RFC 3187 (the namespace registration of the ISBN
> namespace), all the URN namespace specific strings in the ISBN namespace
> must be ISBNs. So every URN:ISBN URI must contain a valid ISBN.
>...

Yes. But that doesn't make the URI a ISBN.

Best regards, Julian

From evnikita2@gmail.com  Thu Aug  4 20:58:43 2011
Return-Path: <evnikita2@gmail.com>
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 671DD11E80B6 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 20:58:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.557
X-Spam-Level: 
X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=-0.758, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B9SEbNrtH4GW for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 20:58:42 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC9011E80A7 for <urn@ietf.org>; Thu,  4 Aug 2011 20:58:41 -0700 (PDT)
Received: by fxe6 with SMTP id 6so3002002fxe.31 for <urn@ietf.org>; Thu, 04 Aug 2011 20:58:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=F0lkcsw8X4jYbhSi6jnmEIV6XE1Ku7xCDubMN1h1Bis=; b=JndSaJJl8RnB/VUl2i8mjXdHEu+ZE5XNKU4kpB/6qC0vX5n/DI2/H0/QK5ddt9iu/A O3z7hv0FZrn+adnIGHjqAodAI9XK6VQcGKCWZQGkdP4W9YKAi31mfC7FoRiYLKuKe3IC eVQGAp9lTQPiIMCInZhnp0rrd3Ro5C5z4cRQo=
Received: by 10.223.17.151 with SMTP id s23mr2197033faa.13.1312516737114; Thu, 04 Aug 2011 20:58:57 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id h9sm1665448faa.39.2011.08.04.20.58.55 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 20:58:55 -0700 (PDT)
Message-ID: <4E3B6AA6.80901@gmail.com>
Date: Fri, 05 Aug 2011 06:59:34 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi>
In-Reply-To: <4E3A7ABA.7060500@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 05 Aug 2011 03:58:43 -0000

04.08.2011 13:55, Juha Hakala wrote:
> Privyet Mykyta; Hello all,

Well, Ave, Juha,

>
> Some comments below.

See my responses ibidem :-)

>
> Mykyta Yevstifeyev wrote:
>
>>> Clarifying: the RFC 3986 requirement is:
>>>
>>> "The semantics of a fragment identifier are defined by the set of 
>>> representations that might result from a retrieval action on the 
>>> primary resource. The fragment's format and resolution is therefore 
>>> dependent on the media type [RFC2046] of a potentially retrieved 
>>> representation, even though such a retrieval is only performed if 
>>> the URI is dereferenced. If no such representation exists, then the 
>>> semantics of the fragment are considered unknown and are effectively 
>>> unconstrained. Fragment identifier semantics are independent of the 
>>> URI scheme and thus cannot be redefined by scheme specifications." 
>>> -- <http://greenbytes.de/tech/webdav/rfc3986.html#rfc.section.3.5.p.2>
>
> I have added a reference to media type and RFC 2046 into the draft.
>>
>> ... Correspondingly, it is only possible to use the fragment 
>> identifier when the URI/IRI is clear about the media type of the 
>> resource it refers to.  This may be determined from the URI itself or 
>> if it is mandatory that the particular type of a resource identifier 
>> must be resolved to the resource of a particular type.  URN with ISBN 
>> may refer to the text of a book in .txt, .html, .doc, .pdf, .ps, 
>> format or worse; URN with ISBN may refer to the page with book's 
>> annotation in any of the above format; or something else.  It is 
>> impossible to know for sure that "this URN is resolved to 
>> <bla-bla-bla> format", and, correspondingly, use fragment 
>> identifiers.  Here I agree with Juha.
>
> I disagree with Mykyta (but hopefully not with myself :-)).
>
> The reason why URN:ISBN namespace does not allow fragments has to do 
> with ISBN syntax. This is OK:
>
> http://urn.fi/URN:ISBN:978-952-10-7060-0
>
> but I am not allowed to add anything to the namespace specific string 
> even if the media type in which this book is published would allow 
> that. Of course, adding <query> would be OK since it would not be part 
> of the identifier.

Neither would the fragment ID, though.

>
> The URN:ISBN string itself does not imply any media type directly, but 
> ISBN assignment rules make it clear that if the media type changes, a 
> new ISBN must be assigned. The ISBN above belongs to a PDF version to 
> a dissertation; if it is migrated to EPUB 3, a new ISBN is required.

But you should consider that ISBN may also be assigned to printed 
version, which may also be transformed to the electronic form.  In this 
case, even being the same book, the format will be different, and mostly 
likely different from one used to produced printed copy.  Then such 
scanned copies may be entered in the URN resolution system, and the URN 
with ISBN will be resolved to one of such copies.

I also don't actually think that when some person transforms the text of 
the book in the format he/she likes, he/she will request the new ISBN.  
ISBN identify contents, unlike fragment identifiers, which concertize 
contents in terms of media type.

>>
>> With respect to NBNs.  The situation is the same.  The matter of 
>> fragment ID is the type, the format of the resource, not its actual 
>> contents.  The same publication with the unique NBN number may exist 
>> in electronic form in different formats.  Just the same as above.
>
> NBN does not refer to the work, but to a single manifestation of the 
> work (in one file format). Manifestations in different file formats 
> will get a different URN:NBNs. The reason for this is that file format 
> changes may have an impact on the look and feel of the resource, and 
> once something changes, for librarians it is no longer the same thing. 
> We've had similar practices for printed stuff: hard back and paper 
> back versions of a book have different ISBNs.

One of the assumptions of URN namespaces is global uniqueness.  From RFC 
1737:

>     o  Global uniqueness: The same URN will never be assigned to two
>        different resources.

and therefore I don't understand URNs for NBNs with such identifier 
possible to be assigned twice or more to the same resource.  If the work 
doesn't change, the URN must be stable.

>
> There is an interesting problem that all digital manifestations will 
> be short-lived. When URN:ISBNs and URN:NBNs are not moved over to more 
> modern versions of the document (which will receive other URNs) then 
> somehow we must guarantee that the users will be made aware that there 
> are later versions available as well.
>
> Other URN namespaces may be more flexible than the ones we are dealing 
> now. We could have for instance urn:mykyta where the rule is that the 
> file format does not matter. I don't know how much we can /should do 
> in RFCs to co-ordinate those namespaces that deal with digital 
> manifestations. Works are of course a different matter altogether, 
> since they are immaterial and as such persistent.
>
> Independently of any physical manifestations libraries will also 
> describe and identify works, but then we do not use ISBN but ISTC 
> (International standard text code) for textual resources. And 
> registering a namespace for that identifier (which has just recently 
> went into production) remains to be done.

NBN namespace, with what you've said, break the aforementioned 
assumption for URNs; different manifestations of a similar work 
shouldn't have different URNs, I'll repeat.  So I suppose the case with 
NBNs isn't generally applicable to the URNs.  (It also breaks the 
"persistence" principle, which means that one URN will identify the 
resource forever.  With NBNs, which may change depending on the version 
of the resource and its format, it isn't possible to persistently refer 
to the "newest version".)

>
>> So, my position is that defining the fragment ID for use with ISBN 
>> and NBN URNs makes very little sense; they may only be useful in URNs 
>> which have very limited scope and resolve to the resource of the type 
>> which is predefined.
>
> My take on this is that if we have e.g. a book in a file format that 
> allows specification of fragments, then it is possible that these 
> fragments can be accessed directly using HTTP URIs, and improving 
> persistence of these access points to with URNs may make sense.

And I'll ask the same question - how do you determine the format a 
particular URN may theoretically be resolved to?

>
> In case of multimedia documents (with a multitude of file formats), 
> URN:NBNs must be assigned at the file format level if the intention is 
> to use fragments in one or more of these formats.
>>
>> (BTW: Fragment IDs, per RFC 3986, are allowed to be present in any 
>> URI, including URN; however, they cannot be effectively handled in 
>> the latter case.  I think RFC 2141bis should be clear that this part 
>> of an URI, if present, should be ignored).
>>
>> (BTW2: Is new revision of 2141bis going to be published soon?)
>
> Alfred Hoenes indicated before his summer vacation that he plans to 
> concentrate on URNBIS work during the first half of August.

Thanks for info.

Mykyta

>
> Best regards,
>
> Juha
>>
>> Mykyta Yevstifeyev
>>
>>>
>>> Best regards, Julian
>>> _______________________________________________
>>> urn mailing list
>>> urn@ietf.org
>>> https://www.ietf.org/mailman/listinfo/urn
>>>
>>
>> _______________________________________________
>> urn mailing list
>> urn@ietf.org
>> https://www.ietf.org/mailman/listinfo/urn
>>
>


From evnikita2@gmail.com  Thu Aug  4 21:03:14 2011
Return-Path: <evnikita2@gmail.com>
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 36CBE11E80BB for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 21:03:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.15
X-Spam-Level: 
X-Spam-Status: No, score=-3.15 tagged_above=-999 required=5 tests=[AWL=-0.151,  BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9z2I19u4oPNM for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 21:03:13 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6317311E80A7 for <urn@ietf.org>; Thu,  4 Aug 2011 21:03:13 -0700 (PDT)
Received: by fxe6 with SMTP id 6so3005190fxe.31 for <urn@ietf.org>; Thu, 04 Aug 2011 21:03:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=DYdHK0jKq8rbiCzoKNTg8CvsgPHxK3zQUhGkUuIjskQ=; b=EcoYC3OqUtckPSLYdxynk4AtU3rM3xxNOKLiTvwSa/89j9JE4E1Pa9Fchsdkwaxeiq QBT3145YD3BLQTxiTNODU7WXMZHc0k/Cd+yeZnqi96mXp7flhGB4AjgTCA/1b9E7A/V1 TUYumsewWTfiyVf8qi8XL03y5LszpKK61S0tg=
Received: by 10.223.159.207 with SMTP id k15mr2221822fax.82.1312517006953; Thu, 04 Aug 2011 21:03:26 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id f27sm1673422fak.7.2011.08.04.21.03.24 (version=SSLv3 cipher=OTHER); Thu, 04 Aug 2011 21:03:25 -0700 (PDT)
Message-ID: <4E3B6BB4.40007@gmail.com>
Date: Fri, 05 Aug 2011 07:04:04 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3A7FE3.8090301@gmx.de> <4E3A86AE.60000@helsinki.fi>
In-Reply-To: <4E3A86AE.60000@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 05 Aug 2011 04:03:14 -0000

04.08.2011 14:46, Juha Hakala wrote:
> Hello,
>
> Julian Reschke wrote:
>
>>> but I am not allowed to add anything to the namespace specific string
>>> even if the media type in which this book is published would allow 
>>> that.
>>> Of course, adding <query> would be OK since it would not be part of the
>>> identifier.
>> > ...
>>
>> I don't believe an URI scheme (and thereby an URN namespace) can make 
>> this restriction.
>
> ISBN can and must. If you add e.g. a fragment identifier to the end of 
> the URN:ISBN string, the resulting identifier is not an ISBN anymore. 
> Of course the new identifier can still be a valid URI and it may 
> belong to some other URN namespace such as NBN.

 From RFC 3187 it's clear that URN with no queries or fragments is 
"urn:isbn:<isbn-number>" and that's all.  Please consider that fragment 
ID won't override the ISBN number, if appended.  However, I'm opposed to 
fragment IDs here.

>
>>> The URN:ISBN string itself does not imply any media type directly, but
>>> ISBN assignment rules make it clear that if the media type changes, a
>>> new ISBN must be assigned. The ISBN above belongs to a PDF version to a
>>> dissertation; if it is migrated to EPUB 3, a new ISBN is required.
>>
>> If the ISBN above is guaranteed to identify a PDF document then I 
>> don't see why using a PDF anchor shouldn't work.
>
> An ISBN given to a PDF version of a book must not apply to any other 
> version of that book, or to some other book.
>
> Having said this, there are cases in some countries (which I do not 
> wish to name here) where publishers insist upon giving the same ISBN 
> to all e-versions of a book. In such a case, ISBN does not provide 
> even a reliable starting point for creating an identifier for a 
> fragment in one of these formats. Any standard is only as strong as 
> the weakest link; in this case it is a subset of users who abuse the 
> standard (and may come to regret it later on).

This also seems not to match RFC 1737, "global uniqueness".

Mykyta

>
> Juha
>>
>> > ...
>>
>> Best regards, Julian
>>
>


From juha.hakala@helsinki.fi  Thu Aug  4 22:48:04 2011
Return-Path: <juha.hakala@helsinki.fi>
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 64D7E21F8760 for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 22:48:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Level: 
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JSIrts9aIAeR for <urn@ietfa.amsl.com>; Thu,  4 Aug 2011 22:48:03 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD5221F874F for <urn@ietf.org>; Thu,  4 Aug 2011 22:47:57 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p755m6Rl020433 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 5 Aug 2011 08:48:06 +0300
Message-ID: <4E3B8416.2010307@helsinki.fi>
Date: Fri, 05 Aug 2011 08:48:06 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3B6AA6.80901@gmail.com>
In-Reply-To: <4E3B6AA6.80901@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 05 Aug 2011 05:48:04 -0000

Hello Mykyta; all,

This debate has much to do with how identifiers - and in this case 
particularly ISBN and NBN - are and will be applied in practice, and how 
that relates to URN usage in namespaces. If the aim is to build reliable 
and persistent URN resolution services, we need identifier communities 
with well defined professional practices. The trick is to apply these 
practices in the Internet in a fruitful manner, taking into account the 
requirements of the new environment. If all goes well, both the 
identifier and the IETF communities may learn something in this process.

Since Mykyta brought up many important points about identifiers and 
identification I discuss them at length.

Mykyta Yevstifeyev wrote:

>> The reason why URN:ISBN namespace does not allow fragments has to do 
>> with ISBN syntax. This is OK:
>>
>> http://urn.fi/URN:ISBN:978-952-10-7060-0
>>
>> but I am not allowed to add anything to the namespace specific string 
>> even if the media type in which this book is published would allow 
>> that. Of course, adding <query> would be OK since it would not be part 
>> of the identifier.
> 
> Neither would the fragment ID, though.

That assumption is not correct. According to the RFC2141bis, fragment ID 
- if we allow its use in the URN syntax - will be part of the 
identifier. An identifier which consists of and ISBN and a fragment no 
longer identifies the book as a whole but a component part of it. 
Whereas ISBN with <query> still identifies the book as a whole; the role 
of the <query> is to specify the resolution service the user wants.
> 
>>
>> The URN:ISBN string itself does not imply any media type directly, but 
>> ISBN assignment rules make it clear that if the media type changes, a 
>> new ISBN must be assigned. The ISBN above belongs to a PDF version to 
>> a dissertation; if it is migrated to EPUB 3, a new ISBN is required.
> 
> But you should consider that ISBN may also be assigned to printed 
> version, which may also be transformed to the electronic form.  In this 
> case, even being the same book, the format will be different, and mostly 
> likely different from one used to produced printed copy.  Then such 
> scanned copies may be entered in the URN resolution system, and the URN 
> with ISBN will be resolved to one of such copies.

It should not, at least not automatically. When a book with (or without 
ISBN) is scanned and published in the Web (many national libraries are 
busy with this kind of activity), the resulting digital book shall not 
get an ISBN at all (according to the well established rules of the 
community). So we will end up with URN:ISBN for the printed version and 
URN:NBNs for digitized versions. If the publisher has created "official" 
digital versions, then those will have URN:ISBNs as well.

It is very important that via URN resolution services we can keep track 
on all the manifestations of a book. It is also important to give the 
users the possibility to choose between them, because there is no way of 
knowing in advance which manifestation will fit the needs of the user 
best. He might not know that himself, without some orientation. Some 
people may prefer a modern version, which after many successive 
migrations may be quite different from the original. And some may want 
the original version, even though that means digital archaeology is 
needed to actually read the document.

Interlinking between manifestations can be achieved via well planned 
usage of metadata. All records describing any manifestation of the book 
should contain links to all the other versions. In the future our 
catalogues will contain descriptions of immaterials work such as 
Shakespeare's Hamlet, and these descriptions will contain links to the 
manifestation level records which in turn will contain the actual URN 
links.

This may sound a little bit complicated, but when the aim is to provide 
access to digital resources for centuries, simple solutions will not work.

As an aside, the current resolution services document (RFC 2483) does 
not specify a service for finding all related manifestations of the 
resource. In the late 90s this was not deemed necessary; now even Amazon 
provides it. This indicates at least to me that we can not specify a 
fixed list of resolution services, since the services that are valid at 
any given time depend on the technical infrastructure. It follows that 
it is a bad idea to carve the URN resolution services in stone (specify 
them in a standards track RFC). Instead we need a flexible mechanism 
such as IANA registry where new services can be a registered easily. I 
will start writing a private contribution I-D today to provide a basis 
for this.
> 
> I also don't actually think that when some person transforms the text of 
> the book in the format he/she likes, he/she will request the new ISBN.  
> ISBN identify contents, unlike fragment identifiers, which concertize 
> contents in terms of media type.

ISBN does not identify intellectual content (ISTC does; see 
http://www.istc-international.org/html/). ISBN identifies a particular 
manifestation of the content, such as a paperback or a PDF version of a 
book.

If somebody digitizes as book, it is not possible to acquire an ISBN for 
the resulting book. Another identifier, such as URN:NBN, must be used 
instead.  When digitized books are catalogued, it is a common practice 
to tell that there is a printed version and provide its identifier (ISBN 
or NBN).

> One of the assumptions of URN namespaces is global uniqueness.  From RFC 
> 1737:
> 
>>     o  Global uniqueness: The same URN will never be assigned to two
>>        different resources.
> 
> and therefore I don't understand URNs for NBNs with such identifier 
> possible to be assigned twice or more to the same resource.  If the work 
> doesn't change, the URN must be stable.

As I said above, ISBN identifies manifestations. PDF version of the book 
gets one ISBN, EPUB 3 version get another one, and so on. See

http://www.isbn-international.org/pages/media/101118%20Guidelines%20for%20the%20assignment%20of%20ISBNs%20to%20ebooks.pdf

for details. The raison d'etre for ISBN assignment is derived from book 
trade; anything that is for sale as a separate item must have an ISBN, 
so that the particular manifestation can be told apart from other 
manifestations.

Each time a URN namespace is established, the identifier community 
brings in its own traditions. In some cases the community is not well 
formed; for example I have no idea of what best practices URN:IRI 
community as a whole would have for assigning identifiers. AFAIK well 
defined namespaces such as URN:ISBN will have the best chances of 
actually preserving the resources and resolution services in looong term.

There is a namespace where your view is correct: in the URN:ISTC 
namespace URN will never change as long as the work remains the same. 
When Hamlet is translated to Finnish the translation will of course get 
a new ISTC, but there will be a link to the English original (and to 
translations in other languages, such as Russian and Ukrainian).
>
>> Independently of any physical manifestations libraries will also 
>> describe and identify works, but then we do not use ISBN but ISTC 
>> (International standard text code) for textual resources. And 
>> registering a namespace for that identifier (which has just recently 
>> went into production) remains to be done.
> 
> NBN namespace, with what you've said, break the aforementioned 
> assumption for URNs; different manifestations of a similar work 
> shouldn't have different URNs, I'll repeat.  So I suppose the case with 
> NBNs isn't generally applicable to the URNs.  (It also breaks the 
> "persistence" principle, which means that one URN will identify the 
> resource forever.  With NBNs, which may change depending on the version 
> of the resource and its format, it isn't possible to persistently refer 
> to the "newest version".)

To conclude, there will be namespaces where the identifier identifies 
works (such as ISTC, ISWC, ISAN) and namespaces where manifestations are 
in focus (ISBN, NBN). From the URN point of view, both approaches must 
be correct in the URN system accommodates these namespaces. Of course I 
am assuming here that IETF would approve ISTC namespace registration 
request if the ISTC community produces one.

>> My take on this is that if we have e.g. a book in a file format that 
>> allows specification of fragments, then it is possible that these 
>> fragments can be accessed directly using HTTP URIs, and improving 
>> persistence of these access points to with URNs may make sense.
> 
> And I'll ask the same question - how do you determine the format a 
> particular URN may theoretically be resolved to?

The answer to this will depend on the namespace.

With ISBN, there is always a single manifestation of the book that 
should be retrieved (if the user wants a book). For digital content, 
this approach works for a few decades at most. After a couple of 
centuries it gets a little difficult to carry on like this :-). Please 
note that the time scale for the national libraries really is centuries. 
We may have slightly different notion of persistence than e.g. most web 
developers.

The solution is to provide links between manifestations of the work. 
This will allow the user to pick the one he prefers.

In the URN:ISTC namespace, there is no single manifestation the 
identifier should resolve to. It is up to the user to decide what to do. 
Having started from the English original from Hamlet he may end up 
requesting a digital version of the great Russian Hamlet movie from the 
50s.

Best regards,

Juha
> 
>>
>> In case of multimedia documents (with a multitude of file formats), 
>> URN:NBNs must be assigned at the file format level if the intention is 
>> to use fragments in one or more of these formats.
>>>
>>> (BTW: Fragment IDs, per RFC 3986, are allowed to be present in any 
>>> URI, including URN; however, they cannot be effectively handled in 
>>> the latter case.  I think RFC 2141bis should be clear that this part 
>>> of an URI, if present, should be ignored).
>>>
>>> (BTW2: Is new revision of 2141bis going to be published soon?)
>>
>> Alfred Hoenes indicated before his summer vacation that he plans to 
>> concentrate on URNBIS work during the first half of August.
> 
> Thanks for info.
> 
> Mykyta
> 
>>
>> Best regards,
>>
>> Juha
>>>
>>> Mykyta Yevstifeyev
>>>
>>>>
>>>> Best regards, Julian
>>>> _______________________________________________
>>>> urn mailing list
>>>> urn@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/urn
>>>>
>>>
>>> _______________________________________________
>>> urn mailing list
>>> urn@ietf.org
>>> https://www.ietf.org/mailman/listinfo/urn
>>>
>>
> 
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From leslie@thinkingcat.com  Fri Aug  5 14:02:17 2011
Return-Path: <leslie@thinkingcat.com>
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 8955511E80CC for <urn@ietfa.amsl.com>; Fri,  5 Aug 2011 14:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mFWchCGcJZP for <urn@ietfa.amsl.com>; Fri,  5 Aug 2011 14:02:17 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id CA1C811E80CB for <urn@ietf.org>; Fri,  5 Aug 2011 14:02:16 -0700 (PDT)
Received: from cashmere.local ([::ffff:142.167.234.43]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Fri, 05 Aug 2011 17:02:33 -0400 id 0001802A.4E3C5A69.00003FA3
Message-ID: <4E3C5A68.5010304@thinkingcat.com>
Date: Fri, 05 Aug 2011 17:02:32 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi>
In-Reply-To: <4E3A37FE.7060609@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 05 Aug 2011 21:02:17 -0000

Hi,

I've read the rest of the thread (to date), but will reply at the top:

 > On the basis of the discussion we had in the URNWG meeting during IETF
 > 80, I have assumed that <fragment> feature can be used, but only if RFC
 > 3986 requirements are taken into account. This must be made clear in
 > RFC2141bis, and specified further in namespace registrations. There will
 > be URN namespaces where <fragment> must not be used because the
 > identifier system does not allow it.

The URN WG meeting I was at during IETF80 seemed reasonably clear that 
the options were:

1/ Define how fragments make sense for *ALL* URNs (i.e., not just the 
namespaces of which one is aware) and update the URN specifications 
accordingly.

-- OR --

2/ Include, in the NSS syntax for a given URN namespace, a means of 
identifying what that Namespace means by 'fragment'.


I haven't seen any discussion on this list to accomplish "1/".  (I also 
don't believe it's possible, but that's just a personal technical opinion).

For "2/", you would be in a position to update the ISBN URN NSS syntax. 
    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  So, an 
updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be achievable....?

Leslie.



On 8/4/11 2:11 AM, Juha Hakala wrote:
> Hello all,
>
> I am revising the URN namespace registrations for ISBN and NBN (RFC
> 3187bis and 3188bis). One of the issues that must be dealt with is the
> use of URI <fragment>.
>
> On the basis of the discussion we had in the URNWG meeting during IETF
> 80, I have assumed that <fragment> feature can be used, but only if RFC
> 3986 requirements are taken into account. This must be made clear in
> RFC2141bis, and specified further in namespace registrations. There will
> be URN namespaces where <fragment> must not be used because the
> identifier system does not allow it.
>
> ISBN and NBN (national bibliography number) are in different camps as
> regards URI fragments; the former does not allow them, but the latter
> does. Below are the relevant sections from the new Internet drafts. They
> are complementary in the sense that NBN can be used to identify
> component parts of a book (if they do not have ISBNs of their own).
> Armed with both specifications, national libraries and other users can
> assign identifiers to books and their logical / physical components, to
> the level of specificity desired.
>
> This is what the revised RFC 3187bis says at the moment:
>
> Books are finite objects, which may consist of component parts such as
> chapters or short stories / novellas. Such component parts may in some
> circumstances be given their own ISBNs. If they are not identified, ISBN
> standard does not allow augmentation of the ISBN of the book with URI
> fragments for identification of the component parts. Technically it is
> possible to add URI fragments to ISBN, but the resulting identifier will
> not be an ISBN; it could be a national bibliography number (URN:NBN) or
> an internal, completely non-standard identifier.
>
> This is the corresponding section from RFC3188bis:
>
> Bibliographic objects are finite, and may consist of component parts. If
> the object is a book, these component parts may be articles, chapters,
> short stories / novellas, images and so on. When a bibliographic object
> such as a book is published in electronic form, it may be possible to
> access its component parts directly. If so, a reliable access key is
> needed. NBNs may be assigned to these component parts, depending the
> local NBN assignment policy. In some circumstances (if the stipulations
> of RFC 3986 and RFC2141bis are met), URI fragments can be applied in the
> NBN string.
>
> However, since logical components of a book may not represented as URI
> fragments (and vice versa), component parts will normally be identified
> by using a local method not based on URI Generic syntax. This RFC will
> not specify the NBN method for generating fragment identifiers, since
> some organizations may use any available mechanism for other purposes.
> However, several viable methods can be suggested. For instance, the book
> as a whole may have an ISBN, and the NBNs for the component parts can be
> based on the ISBN. Likewise there may be a base-NBN for the resource
> itself, and extended versions for the logical components. The most
> common approach may be the simplest: assign a separate NBN for each
> component part.
>
> ------------
>
> My aim is that the new versions of 3187bis and 3188bis will be published
> in August.
>
> Best regards,
>
> Juha

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------

From evnikita2@gmail.com  Fri Aug  5 21:20:40 2011
Return-Path: <evnikita2@gmail.com>
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 E4DE011E8099 for <urn@ietfa.amsl.com>; Fri,  5 Aug 2011 21:20:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.445
X-Spam-Level: 
X-Spam-Status: No, score=-2.445 tagged_above=-999 required=5 tests=[AWL=-0.646, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6, J_CHICKENPOX_35=0.6, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re95i2LKtjkj for <urn@ietfa.amsl.com>; Fri,  5 Aug 2011 21:20:37 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id B85DB11E807C for <urn@ietf.org>; Fri,  5 Aug 2011 21:20:36 -0700 (PDT)
Received: by fxe6 with SMTP id 6so4160318fxe.31 for <urn@ietf.org>; Fri, 05 Aug 2011 21:20:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=CQPbIcgK5wbOyP77ed3f2RgzDRIHvpR80oVUOUYs2AY=; b=DrsDfJPk8W1w/Xb1iXYZaFyrepx74PN/lF9U/XVWqj/CVhOQ2H/Y25HXrrfD5UVqJ3 Z4ZeloeHjt2VSmSfl6a++q8BI+xUO7Y6n+h7veo5isH7XgE07LCidAvN8qaBTHK5x3xS 5UFc5rq9mIaK4jF14XVnZHVfIjZrLj2Kxv0N4=
Received: by 10.223.7.66 with SMTP id c2mr3971246fac.35.1312604453726; Fri, 05 Aug 2011 21:20:53 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id v15sm1163554fah.9.2011.08.05.21.20.51 (version=SSLv3 cipher=OTHER); Fri, 05 Aug 2011 21:20:52 -0700 (PDT)
Message-ID: <4E3CC14A.4080201@gmail.com>
Date: Sat, 06 Aug 2011 07:21:30 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Juha Hakala <juha.hakala@helsinki.fi>
References: <4E3A37FE.7060609@helsinki.fi> <4E3A4947.1070209@gmx.de> <4E3A5B9A.9060908@gmail.com> <4E3A7ABA.7060500@helsinki.fi> <4E3B6AA6.80901@gmail.com> <4E3B8416.2010307@helsinki.fi>
In-Reply-To: <4E3B8416.2010307@helsinki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Sat, 06 Aug 2011 04:20:40 -0000

Hi Juha, all,

Having read your explanations, a number of issues were clarified.  First 
of all, you said that ISBN actually focuses of manifestation of a book, 
not its contents; so does NBN number.  I personally don't agree with it, 
as ISBN, IMO, should be meant to identify book's contents uniquely and 
independently of the format they are represented in, but I have nothing 
to do with here.  Please see further comments below.

05.08.2011 8:48, Juha Hakala wrote:
> Hello Mykyta; all,
>
> This debate has much to do with how identifiers - and in this case 
> particularly ISBN and NBN - are and will be applied in practice, and 
> how that relates to URN usage in namespaces. If the aim is to build 
> reliable and persistent URN resolution services, we need identifier 
> communities with well defined professional practices. The trick is to 
> apply these practices in the Internet in a fruitful manner, taking 
> into account the requirements of the new environment. If all goes 
> well, both the identifier and the IETF communities may learn something 
> in this process.
>
> Since Mykyta brought up many important points about identifiers and 
> identification I discuss them at length.
>
> Mykyta Yevstifeyev wrote:
>
>>> The reason why URN:ISBN namespace does not allow fragments has to do 
>>> with ISBN syntax. This is OK:
>>>
>>> http://urn.fi/URN:ISBN:978-952-10-7060-0
>>>
>>> but I am not allowed to add anything to the namespace specific 
>>> string even if the media type in which this book is published would 
>>> allow that. Of course, adding <query> would be OK since it would not 
>>> be part of the identifier.
>>
>> Neither would the fragment ID, though.
>
> That assumption is not correct. According to the RFC2141bis, fragment 
> ID - if we allow its use in the URN syntax - will be part of the 
> identifier. An identifier which consists of and ISBN and a fragment no 
> longer identifies the book as a whole but a component part of it. 
> Whereas ISBN with <query> still identifies the book as a whole; the 
> role of the <query> is to specify the resolution service the user wants.

Strictly at syntactical level, RFC 2141 <NID> and <NSS> form RFC 3986 
<path-rootless>. <fragment> and its preceding "#" is put after <query> 
and its "?", if any, and some sort of path.  So <fragment> cannot be 
considered to be a part of the"path" in the URI.

>>
>>>
>>> The URN:ISBN string itself does not imply any media type directly, 
>>> but ISBN assignment rules make it clear that if the media type 
>>> changes, a new ISBN must be assigned. The ISBN above belongs to a 
>>> PDF version to a dissertation; if it is migrated to EPUB 3, a new 
>>> ISBN is required.
>>
>> But you should consider that ISBN may also be assigned to printed 
>> version, which may also be transformed to the electronic form.  In 
>> this case, even being the same book, the format will be different, 
>> and mostly likely different from one used to produced printed copy.  
>> Then such scanned copies may be entered in the URN resolution system, 
>> and the URN with ISBN will be resolved to one of such copies.
>
> It should not, at least not automatically. When a book with (or 
> without ISBN) is scanned and published in the Web (many national 
> libraries are busy with this kind of activity), the resulting digital 
> book shall not get an ISBN at all (according to the well established 
> rules of the community). So we will end up with URN:ISBN for the 
> printed version and URN:NBNs for digitized versions. If the publisher 
> has created "official" digital versions, then those will have 
> URN:ISBNs as well.

OK, but why eg. Google Books provide search of e-books with ISBNs of 
their printed versions?

>
> It is very important that via URN resolution services we can keep 
> track on all the manifestations of a book. It is also important to 
> give the users the possibility to choose between them, because there 
> is no way of knowing in advance which manifestation will fit the needs 
> of the user best. He might not know that himself, without some 
> orientation. Some people may prefer a modern version, which after many 
> successive migrations may be quite different from the original. And 
> some may want the original version, even though that means digital 
> archaeology is needed to actually read the document.
>
> Interlinking between manifestations can be achieved via well planned 
> usage of metadata. All records describing any manifestation of the 
> book should contain links to all the other versions. In the future our 
> catalogues will contain descriptions of immaterials work such as 
> Shakespeare's Hamlet, and these descriptions will contain links to the 
> manifestation level records which in turn will contain the actual URN 
> links.
>
> This may sound a little bit complicated, but when the aim is to 
> provide access to digital resources for centuries, simple solutions 
> will not work.

Well, if a "manifestation" implies making some changes to the original 
work, I'll doubt it is the same work; so here another identifier is 
necessary.  If "manifestation" means different format of the same work, 
eg. printed, electronic in different formats, etc., I don't think here 
the new identifier is necessary, but if assigning it (I mean ISBNs and 
NBNs) is community-accepted, I have nothing to say.  I consider tracking 
relationships between such resources to be necessary in both cases.

>
> As an aside, the current resolution services document (RFC 2483) does 
> not specify a service for finding all related manifestations of the 
> resource. In the late 90s this was not deemed necessary; now even 
> Amazon provides it. This indicates at least to me that we can not 
> specify a fixed list of resolution services, since the services that 
> are valid at any given time depend on the technical infrastructure. It 
> follows that it is a bad idea to carve the URN resolution services in 
> stone (specify them in a standards track RFC). Instead we need a 
> flexible mechanism such as IANA registry where new services can be a 
> registered easily. I will start writing a private contribution I-D 
> today to provide a basis for this.

I'm looking forward to work on this draft.  Juha, please note that RFC 
3404, DDDS application for resolving URIs and URNs intended to use 
assigned resolution service names, but failed to create corresponding 
registry.  In your draft, it's possible to mention that new registry for 
resolution services may also be useful in this DDDS application.

>>
>> I also don't actually think that when some person transforms the text 
>> of the book in the format he/she likes, he/she will request the new 
>> ISBN.  ISBN identify contents, unlike fragment identifiers, which 
>> concertize contents in terms of media type.
>
> ISBN does not identify intellectual content (ISTC does; see 
> http://www.istc-international.org/html/). ISBN identifies a particular 
> manifestation of the content, such as a paperback or a PDF version of 
> a book.

Even though I don't agree with it, as I've already said, but have 
nothing to say here :-).

>
>
> If somebody digitizes as book, it is not possible to acquire an ISBN 
> for the resulting book. Another identifier, such as URN:NBN, must be 
> used instead.  When digitized books are catalogued, it is a common 
> practice to tell that there is a printed version and provide its 
> identifier (ISBN or NBN).
>
>> One of the assumptions of URN namespaces is global uniqueness.  From 
>> RFC 1737:
>>
>>>     o  Global uniqueness: The same URN will never be assigned to two
>>>        different resources.
>>
>> and therefore I don't understand URNs for NBNs with such identifier 
>> possible to be assigned twice or more to the same resource.  If the 
>> work doesn't change, the URN must be stable.
>
> As I said above, ISBN identifies manifestations. PDF version of the 
> book gets one ISBN, EPUB 3 version get another one, and so on. See
>
> http://www.isbn-international.org/pages/media/101118%20Guidelines%20for%20the%20assignment%20of%20ISBNs%20to%20ebooks.pdf 
>
>
> for details. The raison d'etre for ISBN assignment is derived from 
> book trade; anything that is for sale as a separate item must have an 
> ISBN, so that the particular manifestation can be told apart from 
> other manifestations.
>
> Each time a URN namespace is established, the identifier community 
> brings in its own traditions. In some cases the community is not well 
> formed; for example I have no idea of what best practices URN:IRI 
> community as a whole would have for assigning identifiers. AFAIK well 
> defined namespaces such as URN:ISBN will have the best chances of 
> actually preserving the resources and resolution services in looong term.
>
> There is a namespace where your view is correct: in the URN:ISTC 
> namespace URN will never change as long as the work remains the same. 
> When Hamlet is translated to Finnish the translation will of course 
> get a new ISTC, but there will be a link to the English original (and 
> to translations in other languages, such as Russian and Ukrainian).
>>
>>> Independently of any physical manifestations libraries will also 
>>> describe and identify works, but then we do not use ISBN but ISTC 
>>> (International standard text code) for textual resources. And 
>>> registering a namespace for that identifier (which has just recently 
>>> went into production) remains to be done.
>>
>> NBN namespace, with what you've said, break the aforementioned 
>> assumption for URNs; different manifestations of a similar work 
>> shouldn't have different URNs, I'll repeat.  So I suppose the case 
>> with NBNs isn't generally applicable to the URNs.  (It also breaks 
>> the "persistence" principle, which means that one URN will identify 
>> the resource forever.  With NBNs, which may change depending on the 
>> version of the resource and its format, it isn't possible to 
>> persistently refer to the "newest version".)
>
> To conclude, there will be namespaces where the identifier identifies 
> works (such as ISTC, ISWC, ISAN) and namespaces where manifestations 
> are in focus (ISBN, NBN). From the URN point of view, both approaches 
> must be correct in the URN system accommodates these namespaces. Of 
> course I am assuming here that IETF would approve ISTC namespace 
> registration request if the ISTC community produces one.

ISCT namespace would fit the aforementioned requirement of RFC 1737 
better than ISBN; but if it is an already established practice...

>
>>> My take on this is that if we have e.g. a book in a file format that 
>>> allows specification of fragments, then it is possible that these 
>>> fragments can be accessed directly using HTTP URIs, and improving 
>>> persistence of these access points to with URNs may make sense.
>>
>> And I'll ask the same question - how do you determine the format a 
>> particular URN may theoretically be resolved to?
>
> The answer to this will depend on the namespace.
>
> With ISBN, there is always a single manifestation of the book that 
> should be retrieved (if the user wants a book). For digital content, 
> this approach works for a few decades at most. After a couple of 
> centuries it gets a little difficult to carry on like this :-). Please 
> note that the time scale for the national libraries really is 
> centuries. We may have slightly different notion of persistence than 
> e.g. most web developers.
>
> The solution is to provide links between manifestations of the work. 
> This will allow the user to pick the one he prefers.
>
> In the URN:ISTC namespace, there is no single manifestation the 
> identifier should resolve to. It is up to the user to decide what to 
> do. Having started from the English original from Hamlet he may end up 
> requesting a digital version of the great Russian Hamlet movie from 
> the 50s.

Considered what you've said, it may be possible to specify fragment I-Ds 
to ISBNs.  With respect to NBNs, if one is capable of determining or 
finding up for sure which media type the resource it refers to has, 
fragment IDs can also be possible.

With regard to 2141bis, I think it should allow fragment IDs but mention 
that separate namespaces may define them as allowed or disallowed; for 
those which disallow, fragment ID should be ignored.

Mykyta Yevstifeyev

>
> Best regards,
>
> Juha
>>
>>>
>>> In case of multimedia documents (with a multitude of file formats), 
>>> URN:NBNs must be assigned at the file format level if the intention 
>>> is to use fragments in one or more of these formats.
>>>>
>>>> (BTW: Fragment IDs, per RFC 3986, are allowed to be present in any 
>>>> URI, including URN; however, they cannot be effectively handled in 
>>>> the latter case.  I think RFC 2141bis should be clear that this 
>>>> part of an URI, if present, should be ignored).
>>>>
>>>> (BTW2: Is new revision of 2141bis going to be published soon?)
>>>
>>> Alfred Hoenes indicated before his summer vacation that he plans to 
>>> concentrate on URNBIS work during the first half of August.
>>
>> Thanks for info.
>>
>> Mykyta
>>
>>>
>>> Best regards,
>>>
>>> Juha
>>>>
>>>> Mykyta Yevstifeyev
>>>>
>>>>>
>>>>> Best regards, Julian
>>>>> _______________________________________________
>>>>> urn mailing list
>>>>> urn@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/urn
>>>>>
>>>>
>>>> _______________________________________________
>>>> urn mailing list
>>>> urn@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/urn
>>>>
>>>
>>
>>
>


From stpeter@stpeter.im  Mon Aug  8 09:27:50 2011
Return-Path: <stpeter@stpeter.im>
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 16AF421F8B2F for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 09:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.35
X-Spam-Level: 
X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=-0.351, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, 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 RvutonQU1BZQ for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 09:27:49 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 8212421F8B38 for <urn@ietf.org>; Mon,  8 Aug 2011 09:27:49 -0700 (PDT)
Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 83A55413D9; Mon,  8 Aug 2011 10:29:49 -0600 (MDT)
Message-ID: <4E400E9E.3050204@stpeter.im>
Date: Mon, 08 Aug 2011 10:28:14 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Leslie Daigle <leslie@thinkingcat.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com>
In-Reply-To: <4E3C5A68.5010304@thinkingcat.com>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Mon, 08 Aug 2011 16:27:50 -0000

<hat type='individual'/>

On 8/5/11 3:02 PM, Leslie Daigle wrote:
> Hi,
> 
> I've read the rest of the thread (to date), but will reply at the top:
> 
>> On the basis of the discussion we had in the URNWG meeting during IETF
>> 80, I have assumed that <fragment> feature can be used, but only if RFC
>> 3986 requirements are taken into account. This must be made clear in
>> RFC2141bis, and specified further in namespace registrations. There will
>> be URN namespaces where <fragment> must not be used because the
>> identifier system does not allow it.
> 
> The URN WG meeting I was at during IETF80 seemed reasonably clear that
> the options were:
> 
> 1/ Define how fragments make sense for *ALL* URNs (i.e., not just the
> namespaces of which one is aware) and update the URN specifications
> accordingly.
> 
> -- OR --
> 
> 2/ Include, in the NSS syntax for a given URN namespace, a means of
> identifying what that Namespace means by 'fragment'.
> 
> I haven't seen any discussion on this list to accomplish "1/".  (I also
> don't believe it's possible, but that's just a personal technical opinion).
> 
> For "2/", you would be in a position to update the ISBN URN NSS syntax.
>    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  So, an
> updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be achievable....?

That is consistent with my understanding of the meeting in Prague. I've
been expecting draft-ietf-urnbis-rfc3187bis-isbn-urn-01 to include text
showing how to include fragment identifiers within URNs in the URN:ISBN
namespace.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From andy@hxr.us  Mon Aug  8 12:07:42 2011
Return-Path: <andy@hxr.us>
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 1FE1921F8BB6 for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 12:07:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 fR793rC-hp0Z for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 12:07:41 -0700 (PDT)
Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8F4F021F8AFB for <urn@ietf.org>; Mon,  8 Aug 2011 12:07:41 -0700 (PDT)
Received: by qwc23 with SMTP id 23so1274758qwc.31 for <urn@ietf.org>; Mon, 08 Aug 2011 12:08:08 -0700 (PDT)
Received: by 10.224.187.83 with SMTP id cv19mr4493085qab.8.1312830487815; Mon, 08 Aug 2011 12:08:07 -0700 (PDT)
Received: from zx80.arin.net (core.arin.net [192.149.252.11]) by mx.google.com with ESMTPS id p15sm4591947qct.22.2011.08.08.12.08.06 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 08 Aug 2011 12:08:06 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Andy Newton <andy@hxr.us>
In-Reply-To: <4E3C5A68.5010304@thinkingcat.com>
Date: Mon, 8 Aug 2011 15:06:51 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com>
To: Leslie Daigle <leslie@thinkingcat.com>
X-Mailer: Apple Mail (2.1084)
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Mon, 08 Aug 2011 19:07:42 -0000

On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:

> For "2/", you would be in a position to update the ISBN URN NSS =
syntax.    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  =
So, an updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be =
achievable....?

Do you mean <fragment> as defined by URIs or an NSS specific syntax that =
doesn't conflict with the URI specification?

-andy=

From leslie@thinkingcat.com  Mon Aug  8 12:46:09 2011
Return-Path: <leslie@thinkingcat.com>
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 70B7D11E808D for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 12:46:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level: 
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 AapwGfVmgZI1 for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 12:46:08 -0700 (PDT)
Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by ietfa.amsl.com (Postfix) with ESMTP id DA68C11E8081 for <urn@ietf.org>; Mon,  8 Aug 2011 12:46:08 -0700 (PDT)
Received: from beethoven.local ([::ffff:142.167.236.105]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Mon, 08 Aug 2011 15:46:32 -0400 id 00018035.4E403D18.000029F8
Message-ID: <4E403D15.4070102@thinkingcat.com>
Date: Mon, 08 Aug 2011 15:46:29 -0400
From: Leslie Daigle <leslie@thinkingcat.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Andy Newton <andy@hxr.us>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us>
In-Reply-To: <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Mon, 08 Aug 2011 19:46:09 -0000

Hi,



On 8/8/11 3:06 PM, Andy Newton wrote:
>
> On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:
>
>> For "2/", you would be in a position to update the ISBN URN NSS
>> syntax.    As others have observed -- URN:ISBN:<foo>   is not an
>> ISBN.  So, an updated NSS syntax of URN:ISBN:<foo><fragment>
>> ought to be achievable....?
>
> Do you mean<fragment>  as defined by URIs or an NSS specific syntax
> that doesn't conflict with the URI specification?

The latter -- some NSS specific syntax.

Leslie.

>
> -andy

-- 

-------------------------------------------------------------------
"Reality:
      Yours to discover."
                                 -- ThinkingCat
Leslie Daigle
leslie@thinkingcat.com
-------------------------------------------------------------------

From derhoermi@gmx.net  Mon Aug  8 18:53:56 2011
Return-Path: <derhoermi@gmx.net>
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 790D211E80CA for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 18:53:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.454
X-Spam-Level: 
X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599]
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 mwtRFEsx8bhQ for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 18:53:55 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 4E86811E80B7 for <urn@ietf.org>; Mon,  8 Aug 2011 18:53:55 -0700 (PDT)
Received: (qmail invoked by alias); 09 Aug 2011 01:54:19 -0000
Received: from dslb-094-223-181-191.pools.arcor-ip.net (EHLO HIVE) [94.223.181.191] by mail.gmx.net (mp021) with SMTP; 09 Aug 2011 03:54:19 +0200
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX192phFW5l920lQEoPhKn4aWwg1o3vRrheX4rS26Jz bvd49rKCoqDLE0
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Juha Hakala <juha.hakala@helsinki.fi>
Date: Tue, 09 Aug 2011 03:54:19 +0200
Message-ID: <vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de>
References: <4E3A37FE.7060609@helsinki.fi>
In-Reply-To: <4E3A37FE.7060609@helsinki.fi>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 01:53:56 -0000

* Juha Hakala wrote:
>On the basis of the discussion we had in the URNWG meeting during IETF 
>80, I have assumed that <fragment> feature can be used, but only if RFC 
>3986 requirements are taken into account. This must be made clear in 
>RFC2141bis, and specified further in namespace registrations. There will 
>be URN namespaces where <fragment> must not be used because the 
>identifier system does not allow it.

As I see it, there is a URI layer which sees all URIs. Below it there is
a scheme layer which can see the URI scheme and the scheme-specific part
of the URI. It cannot see the fragment identifier as it is not specific
to individual schemes. So the scheme layer cannot make statements about
fragment identifiers as it is unaware of them. In this sense there can-
not be URN namespaces that say anything about fragment identifiers. This
matches Julian Reschke's interpretation.

Could you explain how you think these terms and concepts fit together?
It seems to me there is confusion here about terminology, but I am not
sure what your mental model here is. There is some nuance about what I
say above, as schemes do get to say how you dereference an identifier,
which in turn affects which representations are available, which affects
how fragment identifiers are interpreted, but that seems out of touch
with how you think about this.

Put differently, as Julian noted, "Fragment identifier semantics are
independent of the URI scheme and thus cannot be redefined by scheme
specifications." How would you reconcile this with your statement above?
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

From moore@network-heretics.com  Mon Aug  8 22:35:48 2011
Return-Path: <moore@network-heretics.com>
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 6E6EE21F8B07 for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 22:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.433
X-Spam-Level: 
X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.165,  BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 xh90SvsUuKnF for <urn@ietfa.amsl.com>; Mon,  8 Aug 2011 22:35:47 -0700 (PDT)
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id C1F9721F8B04 for <urn@ietf.org>; Mon,  8 Aug 2011 22:35:47 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.mail.srv.osa [10.202.2.46]) by gateway1.messagingengine.com (Postfix) with ESMTP id 181DC20839; Tue,  9 Aug 2011 01:36:15 -0400 (EDT)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute6.internal (MEProxy); Tue, 09 Aug 2011 01:36:15 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; s=smtpout; bh=Q4z EORezEIzVNvsHUOZ/NBF1kQM=; b=g/UUn7QKFG0hOGs6nnrghMnBBLZdSHpOB1P BroVsQx92mfk+CfIvazjPyyN3K7srszSPnfBLCOUw8UfMo/VSIyyRDvBZMTtzJTF OeDeMsY0xkzzBBx4Ioa7ouwbKHKsPO2gxazSQ6Mefa+X+JK5Q9qYpx0MZA4Kj17G aCLtz7Nk=
X-Sasl-enc: rTU1TcwzUkorFJjTISqykMOaZaXWujjh2ug6sqEp/06W 1312868174
Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id EA69241A405; Tue,  9 Aug 2011 01:36:13 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary=Apple-Mail-2--446476056
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de>
Date: Tue, 9 Aug 2011 01:36:12 -0400
Message-Id: <53596A74-ED6E-4B89-8010-5FE13B306087@network-heretics.com>
References: <4E3A37FE.7060609@helsinki.fi> <vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
X-Mailer: Apple Mail (2.1084)
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 05:35:48 -0000

--Apple-Mail-2--446476056
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

On Aug 8, 2011, at 9:54 PM, Bjoern Hoehrmann wrote:

> Put differently, as Julian noted, "Fragment identifier semantics are
> independent of the URI scheme and thus cannot be redefined by scheme
> specifications." How would you reconcile this with your statement =
above?

Clearly, fragment identifier semantics are associated with the =
content-type(s) of the resource, not the URI scheme.  How can it work =
any other way?

Keith


--Apple-Mail-2--446476056
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><div>On Aug 8, 2011, at 9:54 PM, Bjoern Hoehrmann wrote:</div><br =
class=3D"Apple-interchange-newline"><blockquote type=3D"cite"><span =
class=3D"Apple-style-span" style=3D"border-collapse: separate; =
font-family: Helvetica; font-style: normal; font-variant: normal; =
font-weight: normal; letter-spacing: normal; line-height: normal; =
orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: =
none; white-space: normal; widows: 2; word-spacing: 0px; =
-webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: =
0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: =
auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Put =
differently, as Julian noted, "Fragment identifier semantics =
are<br>independent of the URI scheme and thus cannot be redefined by =
scheme<br>specifications." How would you reconcile this with your =
statement above?<br></span></blockquote></div><br><div>Clearly, fragment =
identifier semantics are associated with the content-type(s) of the =
resource, not the URI scheme. &nbsp;How can it work any other =
way?</div><div><br></div><div>Keith</div><div><br></div></body></html>=

--Apple-Mail-2--446476056--

From julian.reschke@gmx.de  Tue Aug  9 03:12:52 2011
Return-Path: <julian.reschke@gmx.de>
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 7E54621F888A for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 03:12:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.453
X-Spam-Level: 
X-Spam-Status: No, score=-104.453 tagged_above=-999 required=5 tests=[AWL=-1.854, BAYES_00=-2.599, 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 5zD9Z6zeWy88 for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 03:12:51 -0700 (PDT)
Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 1BA0021F886A for <urn@ietf.org>; Tue,  9 Aug 2011 03:12:50 -0700 (PDT)
Received: (qmail invoked by alias); 09 Aug 2011 10:13:14 -0000
Received: from mail.greenbytes.de (EHLO [192.168.1.140]) [217.91.35.233] by mail.gmx.net (mp049) with SMTP; 09 Aug 2011 12:13:14 +0200
X-Authenticated: #1915285
X-Provags-ID: V01U2FsdGVkX19bveAQ4ZBbwfDMFcTK9hohqHM7bv+IWCaTi2/hVC 9XjIjx0TtKJbcr
Message-ID: <4E410834.2090204@gmx.de>
Date: Tue, 09 Aug 2011 12:13:08 +0200
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Leslie Daigle <leslie@thinkingcat.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us> <4E403D15.4070102@thinkingcat.com>
In-Reply-To: <4E403D15.4070102@thinkingcat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Y-GMX-Trusted: 0
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 10:12:52 -0000

On 2011-08-08 21:46, Leslie Daigle wrote:
> Hi,
>
>
>
> On 8/8/11 3:06 PM, Andy Newton wrote:
>>
>> On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:
>>
>>> For "2/", you would be in a position to update the ISBN URN NSS
>>> syntax. As others have observed -- URN:ISBN:<foo> is not an
>>> ISBN. So, an updated NSS syntax of URN:ISBN:<foo><fragment>
>>> ought to be achievable....?
>>
>> Do you mean<fragment> as defined by URIs or an NSS specific syntax
>> that doesn't conflict with the URI specification?
>
> The latter -- some NSS specific syntax.
>
> Leslie.

+1

Just to clarify: this would mean to use something like

   URN:ISBN:978-952-10-7060-0:chapter1

instead of

   URN:ISBN:978-952-10-7060-0#chapter1

...so it's really mainly a different choice of delimiter...

Best regards, Julian

From stpeter@stpeter.im  Tue Aug  9 08:25:50 2011
Return-Path: <stpeter@stpeter.im>
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 F09C821F8B28 for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 08:25:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.642
X-Spam-Level: 
X-Spam-Status: No, score=-102.642 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, 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 BUpkLdzAYmHY for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 08:25:50 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3610821F8AE1 for <urn@ietf.org>; Tue,  9 Aug 2011 08:25:50 -0700 (PDT)
Received: from dhcp-64-101-72-239.cisco.com (unknown [64.101.72.239]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 7923E413D9; Tue,  9 Aug 2011 09:27:55 -0600 (MDT)
Message-ID: <4E415199.9000602@stpeter.im>
Date: Tue, 09 Aug 2011 09:26:17 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Julian Reschke <julian.reschke@gmx.de>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us> <4E403D15.4070102@thinkingcat.com> <4E410834.2090204@gmx.de>
In-Reply-To: <4E410834.2090204@gmx.de>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 15:25:51 -0000

<hat type='individual'/>

On 8/9/11 4:13 AM, Julian Reschke wrote:
> On 2011-08-08 21:46, Leslie Daigle wrote:
>> Hi,
>>
>>
>>
>> On 8/8/11 3:06 PM, Andy Newton wrote:
>>>
>>> On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:
>>>
>>>> For "2/", you would be in a position to update the ISBN URN NSS
>>>> syntax. As others have observed -- URN:ISBN:<foo> is not an
>>>> ISBN. So, an updated NSS syntax of URN:ISBN:<foo><fragment>
>>>> ought to be achievable....?
>>>
>>> Do you mean<fragment> as defined by URIs or an NSS specific syntax
>>> that doesn't conflict with the URI specification?
>>
>> The latter -- some NSS specific syntax.
>>
>> Leslie.
> 
> +1
> 
> Just to clarify: this would mean to use something like
> 
>   URN:ISBN:978-952-10-7060-0:chapter1
> 
> instead of
> 
>   URN:ISBN:978-952-10-7060-0#chapter1
> 
> ...so it's really mainly a different choice of delimiter...

Agreed. It could be "." or ";" or whatever the community for that
namespace prefers.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From andy@hxr.us  Tue Aug  9 10:05:12 2011
Return-Path: <andy@hxr.us>
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 1BB6821F8CA8 for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 10:05:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level: 
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 Fq0avQr0O6iC for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 10:05:11 -0700 (PDT)
Received: from mail-qy0-f179.google.com (mail-qy0-f179.google.com [209.85.216.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1061721F8C63 for <urn@ietf.org>; Tue,  9 Aug 2011 10:05:10 -0700 (PDT)
Received: by qyk35 with SMTP id 35so112371qyk.10 for <urn@ietf.org>; Tue, 09 Aug 2011 10:05:39 -0700 (PDT)
Received: by 10.224.184.197 with SMTP id cl5mr3687990qab.346.1312909539292; Tue, 09 Aug 2011 10:05:39 -0700 (PDT)
Received: from vpn1t-94.arin.net (core.arin.net [192.149.252.11]) by mx.google.com with ESMTPS id p15sm86726qct.10.2011.08.09.10.05.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 09 Aug 2011 10:05:37 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Andy Newton <andy@hxr.us>
In-Reply-To: <4E415199.9000602@stpeter.im>
Date: Tue, 9 Aug 2011 13:04:19 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <83D2409A-C46C-4A9F-A027-8ACE1CE4590B@hxr.us>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us> <4E403D15.4070102@thinkingcat.com> <4E410834.2090204@gmx.de> <4E415199.9000602@stpeter.im>
To: urn@ietf.org
X-Mailer: Apple Mail (2.1084)
Cc: Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 17:05:12 -0000

On Aug 9, 2011, at 11:26 AM, Peter Saint-Andre wrote:

> <hat type=3D'individual'/>
>=20
> On 8/9/11 4:13 AM, Julian Reschke wrote:
>> Just to clarify: this would mean to use something like
>>=20
>>  URN:ISBN:978-952-10-7060-0:chapter1
>>=20
>> instead of
>>=20
>>  URN:ISBN:978-952-10-7060-0#chapter1
>>=20
>> ...so it's really mainly a different choice of delimiter...
>=20
> Agreed. It could be "." or ";" or whatever the community for that
> namespace prefers.

So we can move forward on this issue, is there any disagreement on this =
approach?

-andy=

From jehakala@mappi.helsinki.fi  Tue Aug  9 11:17:52 2011
Return-Path: <jehakala@mappi.helsinki.fi>
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 8AC8021F8A51 for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 11:17:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300,  BAYES_00=-2.599]
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 qQ7USiZCB3j7 for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 11:17:52 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id AB9C721F89C2 for <urn@ietf.org>; Tue,  9 Aug 2011 11:17:50 -0700 (PDT)
Received: from webmail.helsinki.fi (webmail1-vallila2.fe.helsinki.fi [128.214.173.135]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p79IIEMS011854; Tue, 9 Aug 2011 21:18:15 +0300
Received: from a88-113-47-109.elisa-laajakaista.fi (a88-113-47-109.elisa-laajakaista.fi [88.113.47.109]) by webmail.helsinki.fi (Horde Framework) with HTTP; Tue, 09 Aug 2011 21:18:14 +0300
Message-ID: <20110809211814.340652nkb0xb5ofa.jehakala@webmail.helsinki.fi>
Date: Tue, 09 Aug 2011 21:18:14 +0300
From: jehakala@mappi.helsinki.fi
To: "Andy Newton" <andy@hxr.us>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us> <4E403D15.4070102@thinkingcat.com> <4E410834.2090204@gmx.de> <4E415199.9000602@stpeter.im> <83D2409A-C46C-4A9F-A027-8ACE1CE4590B@hxr.us>
In-Reply-To: <83D2409A-C46C-4A9F-A027-8ACE1CE4590B@hxr.us>
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
Cc: urn@ietf.org, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 09 Aug 2011 18:17:52 -0000

Hello,

Quoting "Andy Newton" <andy@hxr.us>:

>
> On Aug 9, 2011, at 11:26 AM, Peter Saint-Andre wrote:
>
>> <hat type=3D'individual'/>
>>
>> On 8/9/11 4:13 AM, Julian Reschke wrote:
>>> Just to clarify: this would mean to use something like
>>>
>>>  URN:ISBN:978-952-10-7060-0:chapter1
>>>
>>> instead of
>>>
>>>  URN:ISBN:978-952-10-7060-0#chapter1

You cannot use either one of these identifiers in the ISBN namespace. =20
But it is possible to specify another namespace where this kind of =20
syntax is ok, such as NBN.

>>>
>>> ...so it's really mainly a different choice of delimiter...
>>
>> Agreed. It could be "." or ";" or whatever the community for that
>> namespace prefers.
>
> So we can move forward on this issue, is there any disagreement on =20
> this approach?

There are namespaces - including ISBN - which do not accept any kind =20
of fragments, since using them would be against the syntax of the =20
identifier. Namespace registrations must clarify this.

Whenever the namespace does approve fragment use - NBN being an =20
example of this - a namespace specific practice for identifying =20
(logical) fragments can be outlined in the namespace registration =20
request. Even well established standards could consider this kind of =20
practice for the future when the standard is revised. Identifying =20
component parts is one of the big challenges the identifier systems =20
are facing.

As regards NBN, it may not be possible to specify a generic NSS =20
specific delimiter because all the characters that could be used for =20
this purpose may already be in use within the namespace specific =20
strings. Locally (for individual users of the namespace) such =20
practices can easily be developed.

So, the possibility for creating NSS specific delimiters for =20
identification of logical / physical fragments of resources can and =20
IMHO should be mentioned in RFC2141bis.

In addition, I think it would make sense to include the use of =20
<ragment> in 2141bis. Physical fragments of a resource can be =20
identified with URI <fragment>, iff media type allows this and the =20
identifier is attached to a single manifestation of the resource (in =20
the media type level). In such a case the URN will follow the =20
requirements of 3896 and and 2046. I assume that these cases will be =20
relatively rare.

Best regards,

Juha


>
> -andy
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>
>



From evnikita2@gmail.com  Tue Aug  9 21:30:11 2011
Return-Path: <evnikita2@gmail.com>
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 AF9B921F856C for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 21:30:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.062
X-Spam-Level: 
X-Spam-Status: No, score=-3.062 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, RCVD_IN_DNSWL_LOW=-1]
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 ZEw2hkSy6r5v for <urn@ietfa.amsl.com>; Tue,  9 Aug 2011 21:30:11 -0700 (PDT)
Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by ietfa.amsl.com (Postfix) with ESMTP id E080A21F8562 for <urn@ietf.org>; Tue,  9 Aug 2011 21:30:10 -0700 (PDT)
Received: by fxe6 with SMTP id 6so693210fxe.31 for <urn@ietf.org>; Tue, 09 Aug 2011 21:30:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; bh=JTGNoZZN6F8f9GtFcjSO1/eAMEDTCa/DrC0x/RFvOUI=; b=lGeZmj/tLFc2IcXF1hpsWNLQQbIr5WwEBQf6ttMre0X1tiNDVL43W9uvfGfJ4hljUO UrXM5APofUutWSJ3ozzBecjW+i3XRLOden/3gWfdRulgp58KjVp4q2qMB6jEfXcu2MN1 3LRw1Y8cBGopPPksmchtq6nWt0xLBXWwR7wl0=
Received: by 10.223.75.194 with SMTP id z2mr843788faj.89.1312950640817; Tue, 09 Aug 2011 21:30:40 -0700 (PDT)
Received: from [127.0.0.1] ([195.191.104.224]) by mx.google.com with ESMTPS id e10sm440272fak.42.2011.08.09.21.30.39 (version=SSLv3 cipher=OTHER); Tue, 09 Aug 2011 21:30:40 -0700 (PDT)
Message-ID: <4E420996.8020803@gmail.com>
Date: Wed, 10 Aug 2011 07:31:18 +0300
From: Mykyta Yevstifeyev <evnikita2@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: "urn@ietf.org" <urn@ietf.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [urn] Proposal for work on RFC3405bis in URNBIS working group
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 10 Aug 2011 04:30:11 -0000

Hello all,

I've recently posted a message to apps-discuss 
(http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02973.html) describing 
why RFC 3405 needs revising.  As I haven't seen much enthusiasm on this 
proposal at appsawg, I suppose the situation may be different at 
urnbis.  As RFC 3405 was produced by former urn working group, I think 
urnbis may be an appropriate place to perform this work.

Note: I've been always adding Michael Mealling to cc list to my messages 
devoted to RFC 3405, but still haven't received any response.  I'm 
cc'ing this message to him as well.

So, my main issues I'll repeat:

(1) RFC 3405 is based on outdated and obsolete RFC 2717.

(2) Procedures are very fishy; particularly very obscure 
register@uri.arpa and register@urn.arpa lists.

(3) The document should be restructured to make reading easier;

(4) Errata need to be fixed.

I'm glad to hear whether there is enough consensus to perform this work 
in urnbis, and, if yes, whether Michael agrees to be an editor of the 
document, or somebody other is willing to be?

Mykyta Yevstifeyev

From stella@isbn-international.org  Wed Aug 10 02:26:17 2011
Return-Path: <stella@isbn-international.org>
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 25FCD21F8748 for <urn@ietfa.amsl.com>; Wed, 10 Aug 2011 02:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 Ojz8Y4qSCtyv for <urn@ietfa.amsl.com>; Wed, 10 Aug 2011 02:26:16 -0700 (PDT)
Received: from mtaout03-winn.ispmail.ntl.com (mtaout03-winn.ispmail.ntl.com [81.103.221.49]) by ietfa.amsl.com (Postfix) with ESMTP id 0691221F8781 for <urn@ietf.org>; Wed, 10 Aug 2011 02:26:15 -0700 (PDT)
Received: from know-smtpout-4.server.virginmedia.net ([62.254.123.1]) by mtaout03-winn.ispmail.ntl.com (InterMail vM.7.08.04.00 201-2186-134-20080326) with ESMTP id <20110810092638.UFXN5301.mtaout03-winn.ispmail.ntl.com@know-smtpout-4.server.virginmedia.net>; Wed, 10 Aug 2011 10:26:38 +0100
Received: from [86.31.237.152] (helo=StellaGPC) by know-smtpout-4.server.virginmedia.net with esmtp (Exim 4.63) (envelope-from <stella@isbn-international.org>) id 1Qr53d-00030d-Pw; Wed, 10 Aug 2011 10:26:37 +0100
From: "Stella Griffiths \(ISBN\)" <stella@isbn-international.org>
To: <jehakala@mappi.helsinki.fi>, "'Andy Newton'" <andy@hxr.us>
References: <4E3A37FE.7060609@helsinki.fi>	<4E3C5A68.5010304@thinkingcat.com>	<38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us>	<4E403D15.4070102@thinkingcat.com> <4E410834.2090204@gmx.de>	<4E415199.9000602@stpeter.im> <83D2409A-C46C-4A9F-A027-8ACE1CE4590B@hxr.us> <20110809211814.340652nkb0xb5ofa.jehakala@webmail.helsinki.fi>
In-Reply-To: <20110809211814.340652nkb0xb5ofa.jehakala@webmail.helsinki.fi>
Date: Wed, 10 Aug 2011 10:26:43 +0100
Message-ID: <003f01cc573f$9eb5c310$dc214930$@isbn-international.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDh+BFfC4trrZxtPS12pUwSz2PyhgG2DeM0ASFhKWYBg+j7ewIyaBJsAkKwf1IBdEOPmQFw6cLslozhBoA=
Content-Language: en-gb
X-Cloudmark-Analysis: v=1.1 cv=R50lirqlHffDPPkwUlkuVa99MrvKdVWo//yz83qex8g= c=1 sm=0 a=RRrSVEOI81AA:10 a=5aubgfq_CLkA:10 a=j1TOKX53czMA:10 a=IkcTkHD0fZMA:10 a=48vgC7mUAAAA:8 a=0x2Sszbdg0DOJKZG0lgA:9 a=eTVk-IFgEI5HqvzQq7wA:7 a=QEXdDO2ut3YA:10 a=lZB815dzVvQA:10 a=vkzsTE_2XVAA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117
X-Mailman-Approved-At: Wed, 10 Aug 2011 07:00:56 -0700
Cc: urn@ietf.org
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: stella@isbn-international.org
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 10 Aug 2011 09:28:24 -0000

Juha is correct about the use of ISBN namespace. That namespace only =
supports a 13 digit number and not any form of appended fragment =
indicator. Different ISBNs can be used to identify a) the entire =
publication in a specific edition or format and b) to identify a =
particular chapter or fragment of that same publication however.

Stella

-----Original Message-----
From: jehakala@mappi.helsinki.fi [mailto:jehakala@mappi.helsinki.fi]=20
Sent: 09 August 2011 19:18
To: Andy Newton
Cc: urn@ietf.org; Stella Griffiths
Subject: Re: [urn] URNs and URI <fragment>

Hello,

Quoting "Andy Newton" <andy@hxr.us>:

>
> On Aug 9, 2011, at 11:26 AM, Peter Saint-Andre wrote:
>
>> <hat type=3D'individual'/>
>>
>> On 8/9/11 4:13 AM, Julian Reschke wrote:
>>> Just to clarify: this would mean to use something like
>>>
>>>  URN:ISBN:978-952-10-7060-0:chapter1
>>>
>>> instead of
>>>
>>>  URN:ISBN:978-952-10-7060-0#chapter1

You cannot use either one of these identifiers in the ISBN namespace. =20
But it is possible to specify another namespace where this kind of =
syntax is ok, such as NBN.

>>>
>>> ...so it's really mainly a different choice of delimiter...
>>
>> Agreed. It could be "." or ";" or whatever the community for that=20
>> namespace prefers.
>
> So we can move forward on this issue, is there any disagreement on=20
> this approach?

There are namespaces - including ISBN - which do not accept any kind of =
fragments, since using them would be against the syntax of the =
identifier. Namespace registrations must clarify this.

Whenever the namespace does approve fragment use - NBN being an example =
of this - a namespace specific practice for identifying
(logical) fragments can be outlined in the namespace registration =
request. Even well established standards could consider this kind of =
practice for the future when the standard is revised. Identifying =
component parts is one of the big challenges the identifier systems are =
facing.

As regards NBN, it may not be possible to specify a generic NSS specific =
delimiter because all the characters that could be used for this purpose =
may already be in use within the namespace specific strings. Locally =
(for individual users of the namespace) such practices can easily be =
developed.

So, the possibility for creating NSS specific delimiters for =
identification of logical / physical fragments of resources can and IMHO =
should be mentioned in RFC2141bis.

In addition, I think it would make sense to include the use of <ragment> =
in 2141bis. Physical fragments of a resource can be identified with URI =
<fragment>, iff media type allows this and the identifier is attached to =
a single manifestation of the resource (in the media type level). In =
such a case the URN will follow the requirements of 3896 and and 2046. I =
assume that these cases will be relatively rare.

Best regards,

Juha


>
> -andy
> _______________________________________________
> urn mailing list
> urn@ietf.org
> https://www.ietf.org/mailman/listinfo/urn
>
>





From moore@network-heretics.com  Wed Aug 10 13:20:10 2011
Return-Path: <moore@network-heretics.com>
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 B656411E807E for <urn@ietfa.amsl.com>; Wed, 10 Aug 2011 13:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.425
X-Spam-Level: 
X-Spam-Status: No, score=-3.425 tagged_above=-999 required=5 tests=[AWL=0.174,  BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 B30NUWdJH4-c for <urn@ietfa.amsl.com>; Wed, 10 Aug 2011 13:20:10 -0700 (PDT)
Received: from out3.smtp.messagingengine.com (out3.smtp.messagingengine.com [66.111.4.27]) by ietfa.amsl.com (Postfix) with ESMTP id ECD9A11E8073 for <urn@ietf.org>; Wed, 10 Aug 2011 13:20:09 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.mail.srv.osa [10.202.2.44]) by gateway1.messagingengine.com (Postfix) with ESMTP id A025520D3B; Wed, 10 Aug 2011 16:20:41 -0400 (EDT)
Received: from frontend2.messagingengine.com ([10.202.2.161]) by compute4.internal (MEProxy); Wed, 10 Aug 2011 16:20:41 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=CPVEpZz2tBI4FoAvq0Qu0vxzyu4=; b=ty +kQFLpR3QSCpiqBtrmZ7pjTmPvFoUB3HUwb2J7aI8Ru2EmS6DCRg7relO9Bxk+tV euHcqWHQSDqL+Zzewo95R3mXYCZwjwOwmGOnTzsADhw7U9WhikSpPqzpXu9zE1+x hJ2GC8SZ4OIAVvd41qFrMOHS0I40zDTeTenD/QBvs=
X-Sasl-enc: P1VuVioIyF6NtEszhsWVr2Cr7S9OyG4vWRS+gaJ0M5jb 1313007641
Received: from host65-16-145-177.birch.net (host65-16-145-177.birch.net [65.16.145.177]) by mail.messagingengine.com (Postfix) with ESMTPA id 6D2FF45C61A; Wed, 10 Aug 2011 16:20:40 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <4E403D15.4070102@thinkingcat.com>
Date: Wed, 10 Aug 2011 16:20:39 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <B25D8C6D-77B7-4894-A734-EBC7271A22A6@network-heretics.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com> <38228F1B-66AC-47EF-837B-13BEC9AC708E@hxr.us> <4E403D15.4070102@thinkingcat.com>
To: Leslie Daigle <leslie@thinkingcat.com>
X-Mailer: Apple Mail (2.1084)
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 10 Aug 2011 20:20:10 -0000

On Aug 8, 2011, at 3:46 PM, Leslie Daigle wrote:

> Hi,

> On 8/8/11 3:06 PM, Andy Newton wrote:
>>=20
>> On Aug 5, 2011, at 5:02 PM, Leslie Daigle wrote:
>>=20
>>> For "2/", you would be in a position to update the ISBN URN NSS
>>> syntax.    As others have observed -- URN:ISBN:<foo>   is not an
>>> ISBN.  So, an updated NSS syntax of URN:ISBN:<foo><fragment>
>>> ought to be achievable....?
>>=20
>> Do you mean<fragment>  as defined by URIs or an NSS specific syntax
>> that doesn't conflict with the URI specification?
>=20
> The latter -- some NSS specific syntax.

A URN can refer to anything, including a portion of another resource =
also named by a URN.   However, it's important to ensure that a URN =
describing a fragment of a resource named by a URN still meets the =
properties of URNs. =20

For instance, if URNs are coined to describe fragments of a resource =
also named by a URN, and the "outer" resource is subject to change in =
such a way that the fragments also change, then the URNs coined to =
describe those fragments may no longer have the same meanings as they =
did when the URNs were originally associated with those fragments.

The problem is that there are two conflicting desires:  One is to =
maintain stable bindings between individual URNs and they resources =
named by them (whether or not those resources are fragments).   The =
other is to keep the syntactic relationship between the "global" URN and =
the "fragment" URNs stable, so that the global URN is derivable from the =
fragment URN, and perhaps, vice versa.   The URN rules require the =
former; the expectation that there can be a syntactic relationship =
between a name of a fragment and the name of the resource containing the =
fragment creates the latter desire.

Of course, if the resource referred to by the "global" URN never changes =
at all, it's not an issue.   And there may be specific characteristics =
of a particular namespace that make it easier for that particular case.  =
But in general, trying to define fragments for URNs is problematic, and =
the syntax is the least of the issues.

Keith


From stpeter@stpeter.im  Thu Aug 11 06:43:39 2011
Return-Path: <stpeter@stpeter.im>
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 2664E21F88A5 for <urn@ietfa.amsl.com>; Thu, 11 Aug 2011 06:43:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.781
X-Spam-Level: 
X-Spam-Status: No, score=-101.781 tagged_above=-999 required=5 tests=[AWL=-0.774, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, J_CHICKENPOX_23=0.6, 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 hLXNqOO5zoCw for <urn@ietfa.amsl.com>; Thu, 11 Aug 2011 06:43:38 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 54DD621F882E for <urn@ietf.org>; Thu, 11 Aug 2011 06:43:38 -0700 (PDT)
Received: from squire.local (unknown [216.17.251.17]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 310E541477; Thu, 11 Aug 2011 07:45:52 -0600 (MDT)
Message-ID: <4E42AFF4.401@stpeter.im>
Date: Wed, 10 Aug 2011 10:21:08 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: Mykyta Yevstifeyev <evnikita2@gmail.com>
References: <4E420996.8020803@gmail.com>
In-Reply-To: <4E420996.8020803@gmail.com>
X-Enigmail-Version: 1.2
OpenPGP: url=https://stpeter.im/stpeter.asc
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>
Subject: Re: [urn] Proposal for work on RFC3405bis in URNBIS working group
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 11 Aug 2011 13:43:39 -0000

<hat type='AD'/>

On 8/9/11 10:31 PM, Mykyta Yevstifeyev wrote:
> Hello all,
> 
> I've recently posted a message to apps-discuss
> (http://www.ietf.org/mail-archive/web/apps-discuss/current/msg02973.html) describing
> why RFC 3405 needs revising.  As I haven't seen much enthusiasm on this
> proposal at appsawg, I suppose the situation may be different at
> urnbis.  As RFC 3405 was produced by former urn working group, I think
> urnbis may be an appropriate place to perform this work.

The URNBIS WG is having trouble producing even the deliverables on its
current charter. Additional work is inappropriate.

> Note: I've been always adding Michael Mealling to cc list to my messages
> devoted to RFC 3405, but still haven't received any response.  I'm
> cc'ing this message to him as well.

As far as I know, Michael isn't paying attention to IETF work anymore
because he's having so much fun in the space industry.

> So, my main issues I'll repeat:
> 
> (1) RFC 3405 is based on outdated and obsolete RFC 2717.

But RFC 4395 updated RFC 2717, and I think people can figure out from
RFC 4395 that the notion of URI trees has been deprecated.

> (2) Procedures are very fishy; particularly very obscure
> register@uri.arpa and register@urn.arpa lists.

The procedures are defined quite clearly in RFC 3405. Are you sure that
the problem is simply that no one cares about inserting NAPTR records
into the 'URI.ARPA' and 'URN.ARPA' zones?

> (3) The document should be restructured to make reading easier;
> 
> (4) Errata need to be fixed.

If we revised every RFC that had errata or could be made easier to read,
we'd be very busy working on things that most people simply don't care
about.

> I'm glad to hear whether there is enough consensus to perform this work
> in urnbis, 

The responsible Area Director (c'est moi) is strongly opposed to wasting
time discussing even the possibility of taking on this work, until and
unless the WG finishes the items on its current charter.

> and, if yes, whether Michael agrees to be an editor of the
> document, or somebody other is willing to be?

I very much doubt that Michael will work on this.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



From juha.hakala@helsinki.fi  Mon Aug 22 05:33:26 2011
Return-Path: <juha.hakala@helsinki.fi>
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 A5D6321F8B2D for <urn@ietfa.amsl.com>; Mon, 22 Aug 2011 05:33:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.074
X-Spam-Level: 
X-Spam-Status: No, score=-2.074 tagged_above=-999 required=5 tests=[AWL=0.525,  BAYES_00=-2.599]
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 WK1GqP7PxkEu for <urn@ietfa.amsl.com>; Mon, 22 Aug 2011 05:33:25 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 4557721F8B29 for <urn@ietf.org>; Mon, 22 Aug 2011 05:33:23 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p7MCYKSh026854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 22 Aug 2011 15:34:21 +0300
Message-ID: <4E524CCC.4010800@helsinki.fi>
Date: Mon, 22 Aug 2011 15:34:20 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Leslie Daigle <leslie@thinkingcat.com>
References: <4E3A37FE.7060609@helsinki.fi> <4E3C5A68.5010304@thinkingcat.com>
In-Reply-To: <4E3C5A68.5010304@thinkingcat.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Mon, 22 Aug 2011 12:33:26 -0000

Hello Leslie; all,

Leslie Daigle wrote:

> The URN WG meeting I was at during IETF80 seemed reasonably clear that 
> the options were:
> 
> 1/ Define how fragments make sense for *ALL* URNs (i.e., not just the 
> namespaces of which one is aware) and update the URN specifications 
> accordingly.
> 
> -- OR --
> 
> 2/ Include, in the NSS syntax for a given URN namespace, a means of 
> identifying what that Namespace means by 'fragment'.
> 
> 
> I haven't seen any discussion on this list to accomplish "1/".  (I also 
> don't believe it's possible, but that's just a personal technical opinion).

I am pretty certain that 1/ cannot be achieved, not least because this 
has not been the approach chosen by the WG. No generic specification can 
be exhaustive, given the diversity of the identifier systems / 
namespaces / media types. Also, we cannot take into account in the 
abstract level the logical fragments of publications, as namespaces tend 
to see and deal with them differently.

However, generic principles (for instance, the requirement that the 
identifier must only apply to a single manifestation of a resource, and 
the identified media type in that manifestation must support fragments) 
can be given in RFC 2141bis. RFC2141bis should also stipulate that 
namespaces can have their internal fragment specifications which will be 
understood by resolvers that deal with that particular namespace.

> For "2/", you would be in a position to update the ISBN URN NSS syntax. 

I have already done this for the new versions of ISBN and NBN namespace 
registrations, which I hope to be able to send to the list fairly soon. 
The XML sources are ready, but I need technical help to convert the 
documents into I-Ds.

As regards RFC2141bis, I can (in case Alfred Hoenes does not have time 
for that) edit the fragment related section of the latest I-D if I get 
the XML source.

>    As others have observed -- URN:ISBN:<foo>  is not an ISBN.  So, an 
> updated NSS syntax of URN:ISBN:<foo><fragment>  ought to be achievable....?

Sorry, it is not. Please observe that RFC 3187 makes it pretty clear 
that in the ISBN namespace namespace specific string must be an ISBN and 
nothing else. So in URN:ISBN:<foo> = URN:ISBN:<ISBN-string>. ISBN with a 
fragment identifier or anything else added to it is not an ISBN anymore 
and does not belong to the ISBN namespace. For this kind of identifier 
construct, another namespace such as NBN can be used, if local NBN 
assignment policy approves this.

So URN:NBN:<foo><fragment> is certainly achievable, and there may be / 
will be other namespaces out there where <foo><fragment> is also 
acceptable.

Concerning the NBN namespace, given the broad scope of allowed / used 
syntaxes, URI fragment is the only way in which fragments can be 
generally expressed in the identifier syntax. New namespaces may specify 
their own fragment architectures for those cases when RFC3986 & 2046 
requirements are not fulfilled, but retrospectively such changes may be 
impossible or at least complicated to implement. Such namespace specific 
arrangements should be referred to in RFC2141bis in the abstract, but 
they can only be specified in the namespace level.

To sum up,

1. In the RFC 2141bis, there should be some general principles 
concerning the <fragment> use, derived from the requirements contained 
in URI Generic syntax and other principles (such as identification being 
manifestation specific).

2. In addition, namespaces may have their own policies as regards 
identification of fragments. Logical fragments (such as chapters of a 
book published as separate files) shall always be dealt with according 
to the identifier assignment policy (in the ISBN namespace, each chapter 
can get its own ISBN) independently of RFC 3986. Fragments in the URI 
syntax sense is the area where URI Generic syntax will and must be taken 
into account. However some namespaces (such as ISBN) will prevent this 
kind of URNs, due to the requirements of the identifier system.

3. If URI <fragment> is used, identifier must apply to the single 
manifestation of the resource only. This is a normal approach of many 
but not all bibliographic identifiers.

4. If multiple/all manifestations are covered by single identifier, 
fragments must no be used. Moreover, namespace registration request 
should outline the resolution process down to the level of manifestions. 
For instance, with ISTC (identifier for textual works) the primary 
target is the work level metadata, from which a user can get links to 
the manifestations.

Juha
> 
> Leslie.
> 
> 
> 
> On 8/4/11 2:11 AM, Juha Hakala wrote:
>> Hello all,
>>
>> I am revising the URN namespace registrations for ISBN and NBN (RFC
>> 3187bis and 3188bis). One of the issues that must be dealt with is the
>> use of URI <fragment>.
>>
>> On the basis of the discussion we had in the URNWG meeting during IETF
>> 80, I have assumed that <fragment> feature can be used, but only if RFC
>> 3986 requirements are taken into account. This must be made clear in
>> RFC2141bis, and specified further in namespace registrations. There will
>> be URN namespaces where <fragment> must not be used because the
>> identifier system does not allow it.
>>
>> ISBN and NBN (national bibliography number) are in different camps as
>> regards URI fragments; the former does not allow them, but the latter
>> does. Below are the relevant sections from the new Internet drafts. They
>> are complementary in the sense that NBN can be used to identify
>> component parts of a book (if they do not have ISBNs of their own).
>> Armed with both specifications, national libraries and other users can
>> assign identifiers to books and their logical / physical components, to
>> the level of specificity desired.
>>
>> This is what the revised RFC 3187bis says at the moment:
>>
>> Books are finite objects, which may consist of component parts such as
>> chapters or short stories / novellas. Such component parts may in some
>> circumstances be given their own ISBNs. If they are not identified, ISBN
>> standard does not allow augmentation of the ISBN of the book with URI
>> fragments for identification of the component parts. Technically it is
>> possible to add URI fragments to ISBN, but the resulting identifier will
>> not be an ISBN; it could be a national bibliography number (URN:NBN) or
>> an internal, completely non-standard identifier.
>>
>> This is the corresponding section from RFC3188bis:
>>
>> Bibliographic objects are finite, and may consist of component parts. If
>> the object is a book, these component parts may be articles, chapters,
>> short stories / novellas, images and so on. When a bibliographic object
>> such as a book is published in electronic form, it may be possible to
>> access its component parts directly. If so, a reliable access key is
>> needed. NBNs may be assigned to these component parts, depending the
>> local NBN assignment policy. In some circumstances (if the stipulations
>> of RFC 3986 and RFC2141bis are met), URI fragments can be applied in the
>> NBN string.
>>
>> However, since logical components of a book may not represented as URI
>> fragments (and vice versa), component parts will normally be identified
>> by using a local method not based on URI Generic syntax. This RFC will
>> not specify the NBN method for generating fragment identifiers, since
>> some organizations may use any available mechanism for other purposes.
>> However, several viable methods can be suggested. For instance, the book
>> as a whole may have an ISBN, and the NBNs for the component parts can be
>> based on the ISBN. Likewise there may be a base-NBN for the resource
>> itself, and extended versions for the logical components. The most
>> common approach may be the simplest: assign a separate NBN for each
>> component part.
>>
>> ------------
>>
>> My aim is that the new versions of 3187bis and 3188bis will be published
>> in August.
>>
>> Best regards,
>>
>> Juha
> 

-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

From juha.hakala@helsinki.fi  Tue Aug 23 03:47:33 2011
Return-Path: <juha.hakala@helsinki.fi>
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 A5F8F21F8A55 for <urn@ietfa.amsl.com>; Tue, 23 Aug 2011 03:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.179
X-Spam-Level: 
X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.420,  BAYES_00=-2.599]
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 6U-5123FGu0D for <urn@ietfa.amsl.com>; Tue, 23 Aug 2011 03:47:32 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id 657BA21F893C for <urn@ietf.org>; Tue, 23 Aug 2011 03:47:31 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p7NAmRTU016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 23 Aug 2011 13:48:27 +0300
Message-ID: <4E53857A.4000209@helsinki.fi>
Date: Tue, 23 Aug 2011 13:48:26 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Bjoern Hoehrmann <derhoermi@gmx.net>
References: <4E3A37FE.7060609@helsinki.fi> <vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de>
In-Reply-To: <vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "urn@ietf.org" <urn@ietf.org>, Stella Griffiths <stella@isbn-international.org>
Subject: Re: [urn] URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Tue, 23 Aug 2011 10:47:33 -0000

Hello Bjoern; all,

I think some level of initial confusion is natural when we have two 
communities (IETF and people who work with bibliographic identifiers) 
with differing ideas and terminology as regards what a fragment is and 
how they can and should be identified.

But such initial diversity should not prevent us from finding a solution 
which will be acceptable for both communities and beneficial for the URN 
users.

 From the point of view of a bibliographic community, the primary 
interest is what I have called logical fragments; for instance, chapters
of a book or articles in a journal issue. Identifier systems typically 
have their own ways of dealing with these fragments. For instance, in
the ISBN namespace each logical fragments gets its own ISBN, while
Serial Item and Contribution Identifier
(http://en.wikipedia.org/wiki/Serial_Item_and_Contribution_Identifier)
allows automated creation of identifiers to journal issues and articles.
Neither of these identifier systems rely on fragments as specified in 
RFC 3986. But URN resolvers that deal with these identifiers shall be 
able to supply the relevant logical fragment (or whatever related 
service) to the user.

Thus fragment identification will often be dealt with in the namespace 
level, using the standard-based practices of the particular identifier 
community. These practices are not based on RFC 3986, as ISBN and SICI 
indicate. And if this were all there is, there would have been no need 
to say anything about RFC 3986 -based URI fragments in either the URN 
Generic syntax or namespace registrations.

However, there are URN namespaces in which the possibility of using 
RFC3986-based URI fragments exists, on the basis of the identifier 
syntax & assignment policy. And such functionality may be useful, which 
is why Alfred Hoenes and myself decided to propose fragment usage in 
RFC2141bis and namespace registrations (when applicable).

One namespace which can be "fragmented" is NBN (National bibliography 
number) specified in RFC 3188. Given the diversity of NBN systems used 
by different national libraries, there is no way to nail down a non-RFC 
3986 -based generic means for specifying fragments in the NBN namespace 
(such as saying that "." is the delimiter between the two parts of the 
identifier). In such case, using URI fragment may come handy. For 
instance, one URN implementation project has analyzed the possibilities 
for using URI fragments to identify elements of research data within a 
database.

Bjoern Hoehrmann wrote:

> As I see it, there is a URI layer which sees all URIs. Below it there is
> a scheme layer which can see the URI scheme and the scheme-specific part
> of the URI. It cannot see the fragment identifier as it is not specific
> to individual schemes. So the scheme layer cannot make statements about
> fragment identifiers as it is unaware of them. In this sense there can-
> not be URN namespaces that say anything about fragment identifiers. This
> matches Julian Reschke's interpretation.

This may be due to the terminological issues or my ignorance, but I fail 
to see why we couldn't establish a URN namespace which includes fragment 
identifier in the URI generic syntax sense of the word. URNs are URIs, 
and the generic syntax which applies to the URIs should apply to URNs as 
well, unless there are some clear technical reasons why this cannot be 
the case.

> Could you explain how you think these terms and concepts fit together?
> It seems to me there is confusion here about terminology, but I am not
> sure what your mental model here is. There is some nuance about what I
> say above, as schemes do get to say how you dereference an identifier,
> which in turn affects which representations are available, which affects
> how fragment identifiers are interpreted, but that seems out of touch
> with how you think about this.

If a URN contains a fragment in the RFC 3986 sense of the word, then 
resolving or dereferencing that identifier should provide (among other 
things) direct access to the fragment. This functionality should be 
similar to how URLs with fragments work, except for permanence.

Preserving access to a particular file (such as a document in PDF 
format) for long term (centuries) is of course very hard or impossible; 
objects will usually be migrated. But most bibliographical identifiers 
are tied to particular manifestations. When a book in PDF format is 
migrated to, say, OOXML, the new manifestation will get another 
identifier / URN. The new manifestation may no longer have the same 
internal structure and therefore it is possible that the URI fragments 
cannot be used in the same manner.

There is a more general problem of how to provide persistent links to 
resources when any digital manifestation of a resource is doomed to 
become non-accessible eventually. Library community has not developed a 
general answer to this, but one possibility is to encourage creation of 
URN links primarily to the description of the work. In this case, 
dereferencing would provide a metadata record (with links to the 
existing manifestations of the work), or perhaps all or at least some 
manifestations of the resource at one go. What I do not know is how URI 
generic syntax is applicable to this or to the flexibility provided with 
URN resolution services in general in its current form.

IMHO those namespaces which do not identify objects in the manifestation 
level cannot use URI syntax -based physical fragments.

> Put differently, as Julian noted, "Fragment identifier semantics are
> independent of the URI scheme and thus cannot be redefined by scheme
> specifications." How would you reconcile this with your statement above?

I am not sure I understand the above statement correctly. If not, please 
explain in plainer terms. But tentatively I would answer by saying that 
in some URN namespaces such as the NBN the generic specification of the 
fragment identifier semantics can and indeed must be based on the URI 
generic syntax. And although in many URN namespaces identifier & 
fragment semantics will indeed be independent of the URI scheme, it may 
be useful to allow usage of fragments based on URI generic syntax in URN 
strings.

Best regards,

Juha
-- 

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678


From bellini@rinascimento-digitale.it  Wed Aug 31 03:45:38 2011
Return-Path: <bellini@rinascimento-digitale.it>
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 3E7BC21F8A6C for <urn@ietfa.amsl.com>; Wed, 31 Aug 2011 03:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.034
X-Spam-Level: *
X-Spam-Status: No, score=1.034 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, FH_HOST_EQ_D_D_D_DB=0.888, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RDNS_DYNAMIC=0.1]
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 iilP06nwUTaI for <urn@ietfa.amsl.com>; Wed, 31 Aug 2011 03:45:37 -0700 (PDT)
Received: from www.posta.rinascimento-digitale.it (93-63-166-139.ip28.fastwebnet.it [93.63.166.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1B03B21F8A67 for <urn@ietf.org>; Wed, 31 Aug 2011 03:45:34 -0700 (PDT)
Content-class: urn:content-classes:message
Date: Wed, 31 Aug 2011 12:47:03 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <28624A4F2DDCD8438038B3AD62014B249BD300@frd01.FRD.LOCAL>
In-Reply-To: <82865DDFC6D34591B1C285CFA901BC93@FRD.LOCAL>
X-MimeOLE: Produced By Microsoft Exchange V6.5
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: [urn] URNs and URI <fragment>
thread-index: AcxhgoJVTw2DQbNHSqe7j3kagYERhwGQspnw
References: <4E3A37FE.7060609@helsinki.fi><vb3147pk3qt33s1ot775anjqen8cntop1t@hive.bjoern.hoehrmann.de> <82865DDFC6D34591B1C285CFA901BC93@FRD.LOCAL>
From: "Emanuele Bellini" <bellini@rinascimento-digitale.it>
To: "Juha Hakala" <juha.hakala@helsinki.fi>
Cc: urn@ietf.org
Subject: [urn] R:  URNs and URI <fragment>
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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, 31 Aug 2011 10:45:38 -0000

Hello Juha, all
Thanks for your work in explaining the identification requirements of =
the national libraries community. We agree with the possibility to use =
the fragment in the RFC 3188 NBN namespace, and there is no reason to =
prevent the use of fragment identifier in the URI generic syntax.=20
Indeed, the use of fragment opens a number of issues under the digital =
preservation point of view. Up to now other solutions such as =
"emulation" can be adopted avoiding the format migration of the content. =
This can save the resolution behaviour of the fragment...but it is still =
an open issue.

Best,

Emanuele Bellini
Fondazione Rinascimento Digitale

-----Messaggio originale-----
Da: urn-bounces@ietf.org [mailto:urn-bounces@ietf.org] Per conto di Juha =
Hakala
Inviato: marted=EC 23 agosto 2011 12:51
A: Bjoern Hoehrmann
Cc: urn@ietf.org; Stella Griffiths
Oggetto: Re: [urn] URNs and URI <fragment>

Hello Bjoern; all,

I think some level of initial confusion is natural when we have two=20
communities (IETF and people who work with bibliographic identifiers)=20
with differing ideas and terminology as regards what a fragment is and=20
how they can and should be identified.

But such initial diversity should not prevent us from finding a solution =

which will be acceptable for both communities and beneficial for the URN =

users.

 From the point of view of a bibliographic community, the primary=20
interest is what I have called logical fragments; for instance, chapters
of a book or articles in a journal issue. Identifier systems typically=20
have their own ways of dealing with these fragments. For instance, in
the ISBN namespace each logical fragments gets its own ISBN, while
Serial Item and Contribution Identifier
(http://en.wikipedia.org/wiki/Serial_Item_and_Contribution_Identifier)
allows automated creation of identifiers to journal issues and articles.
Neither of these identifier systems rely on fragments as specified in=20
RFC 3986. But URN resolvers that deal with these identifiers shall be=20
able to supply the relevant logical fragment (or whatever related=20
service) to the user.

Thus fragment identification will often be dealt with in the namespace=20
level, using the standard-based practices of the particular identifier=20
community. These practices are not based on RFC 3986, as ISBN and SICI=20
indicate. And if this were all there is, there would have been no need=20
to say anything about RFC 3986 -based URI fragments in either the URN=20
Generic syntax or namespace registrations.

However, there are URN namespaces in which the possibility of using=20
RFC3986-based URI fragments exists, on the basis of the identifier=20
syntax & assignment policy. And such functionality may be useful, which=20
is why Alfred Hoenes and myself decided to propose fragment usage in=20
RFC2141bis and namespace registrations (when applicable).

One namespace which can be "fragmented" is NBN (National bibliography=20
number) specified in RFC 3188. Given the diversity of NBN systems used=20
by different national libraries, there is no way to nail down a non-RFC=20
3986 -based generic means for specifying fragments in the NBN namespace=20
(such as saying that "." is the delimiter between the two parts of the=20
identifier). In such case, using URI fragment may come handy. For=20
instance, one URN implementation project has analyzed the possibilities=20
for using URI fragments to identify elements of research data within a=20
database.

Bjoern Hoehrmann wrote:

> As I see it, there is a URI layer which sees all URIs. Below it there =
is
> a scheme layer which can see the URI scheme and the scheme-specific =
part
> of the URI. It cannot see the fragment identifier as it is not =
specific
> to individual schemes. So the scheme layer cannot make statements =
about
> fragment identifiers as it is unaware of them. In this sense there =
can-
> not be URN namespaces that say anything about fragment identifiers. =
This
> matches Julian Reschke's interpretation.

This may be due to the terminological issues or my ignorance, but I fail =

to see why we couldn't establish a URN namespace which includes fragment =

identifier in the URI generic syntax sense of the word. URNs are URIs,=20
and the generic syntax which applies to the URIs should apply to URNs as =

well, unless there are some clear technical reasons why this cannot be=20
the case.

> Could you explain how you think these terms and concepts fit together?
> It seems to me there is confusion here about terminology, but I am not
> sure what your mental model here is. There is some nuance about what I
> say above, as schemes do get to say how you dereference an identifier,
> which in turn affects which representations are available, which =
affects
> how fragment identifiers are interpreted, but that seems out of touch
> with how you think about this.

If a URN contains a fragment in the RFC 3986 sense of the word, then=20
resolving or dereferencing that identifier should provide (among other=20
things) direct access to the fragment. This functionality should be=20
similar to how URLs with fragments work, except for permanence.

Preserving access to a particular file (such as a document in PDF=20
format) for long term (centuries) is of course very hard or impossible;=20
objects will usually be migrated. But most bibliographical identifiers=20
are tied to particular manifestations. When a book in PDF format is=20
migrated to, say, OOXML, the new manifestation will get another=20
identifier / URN. The new manifestation may no longer have the same=20
internal structure and therefore it is possible that the URI fragments=20
cannot be used in the same manner.

There is a more general problem of how to provide persistent links to=20
resources when any digital manifestation of a resource is doomed to=20
become non-accessible eventually. Library community has not developed a=20
general answer to this, but one possibility is to encourage creation of=20
URN links primarily to the description of the work. In this case,=20
dereferencing would provide a metadata record (with links to the=20
existing manifestations of the work), or perhaps all or at least some=20
manifestations of the resource at one go. What I do not know is how URI=20
generic syntax is applicable to this or to the flexibility provided with =

URN resolution services in general in its current form.

IMHO those namespaces which do not identify objects in the manifestation =

level cannot use URI syntax -based physical fragments.

> Put differently, as Julian noted, "Fragment identifier semantics are
> independent of the URI scheme and thus cannot be redefined by scheme
> specifications." How would you reconcile this with your statement =
above?

I am not sure I understand the above statement correctly. If not, please =

explain in plainer terms. But tentatively I would answer by saying that=20
in some URN namespaces such as the NBN the generic specification of the=20
fragment identifier semantics can and indeed must be based on the URI=20
generic syntax. And although in many URN namespaces identifier &=20
fragment semantics will indeed be independent of the URI scheme, it may=20
be useful to allow usage of fragments based on URI generic syntax in URN =

strings.

Best regards,

Juha
--=20

  Juha Hakala
  Senior advisor, standardisation and IT

  The National Library of Finland
  P.O.Box 15 (Unioninkatu 36, room 503), FIN-00014 Helsinki University
  Email juha.hakala@helsinki.fi, tel +358 50 382 7678

_______________________________________________
urn mailing list
urn@ietf.org
https://www.ietf.org/mailman/listinfo/urn




From jehakala@mappi.helsinki.fi  Wed Aug 31 22:56:25 2011
Return-Path: <jehakala@mappi.helsinki.fi>
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 D5FF021F84E6 for <urn@ietfa.amsl.com>; Wed, 31 Aug 2011 22:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.919
X-Spam-Level: 
X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[AWL=-1.379, BAYES_20=-0.74, J_CHICKENPOX_33=0.6, J_CHICKENPOX_34=0.6]
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 h8UpG8PwPido for <urn@ietfa.amsl.com>; Wed, 31 Aug 2011 22:56:25 -0700 (PDT)
Received: from smtp-rs1-vallila2.fe.helsinki.fi (smtp-rs1-vallila2.fe.helsinki.fi [128.214.173.75]) by ietfa.amsl.com (Postfix) with ESMTP id A803B21F84E4 for <urn@ietf.org>; Wed, 31 Aug 2011 22:56:23 -0700 (PDT)
Received: from webmail.helsinki.fi (webmail1-vallila2.fe.helsinki.fi [128.214.173.135]) by smtp-rs1-vallila2.fe.helsinki.fi (8.13.1/8.13.1) with ESMTP id p815vnc3030006; Thu, 1 Sep 2011 08:57:51 +0300
Received: from a88-113-47-109.elisa-laajakaista.fi (a88-113-47-109.elisa-laajakaista.fi [88.113.47.109]) by webmail.helsinki.fi (Horde Framework) with HTTP; Thu, 01 Sep 2011 08:57:49 +0300
Message-ID: <20110901085749.18843tlsjpp5168t.jehakala@webmail.helsinki.fi>
Date: Thu, 01 Sep 2011 08:57:49 +0300
From: jehakala@mappi.helsinki.fi
To: urn@ietf.org
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: [urn] Finding the end of the URN string
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about possible revisions to the definition of Uniform Resource Names <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: Thu, 01 Sep 2011 05:56:25 -0000

Hello all,

RFC2141 has this to say about parsing URN strings embedded in plain text:

"In textual context, a URN ends when an octet/character from the
excluded character set (<excluded>) is encountered.  The character
from the excluded character set is NOT part of the URN."

Although URNs will usually be incorporated in Dublin Core and other =20
kind of metadata records where the encoding makes the data machine =20
understandable, it may be useful or even necessary to discuss the =20
issue of URN parsing in plain text in more detail in RFC 2141bis. And =20
unlike back in 1997 we know a lot how URNs are used in textual context.

The problem with the current statement is that there is no guarantee =20
that the first character after the URN string is from the excluded =20
character set. For instance, International Standard Name Identifier

urn:isni:1111222233334444

could be followed by the telephone number of the person / organization =20
to whom the ISNI belongs to. This information would not be part of the =20
ISNI, but RFC 2141 would fail in making this clear.

In order to be able to parse URNs in plain text in reliable manner, =20
applications must be aware of the syntax of the identifier system. For =20
instance, there are 16 digits in ISNI, which makes it easy to find the =20
end of the NSS.

ISBNs assigned since 2007 consist of 13 digits, like this:

urn:isbn:978-0-07-166346-5

(As an aside, Principles of Digital Audio, 6th ed., to which this ISBN =20
belongs to, contains a chapter which explains the structure of ISBN. I =20
was a little bit surprised.)

Applications parsing urn:isbn's based on the new ISBN standard must =20
know that the NSS should consist of 13 digits. Therefore, if somebody =20
builds URNs like these:

urn:isbn:<isbn-string>.<foo> (where "." is a local fragment separator)

or

urn:isbn:<isbn-string>#<foo>

or

urn:isbn:<isbn-string>?<foo>

the ISBN parsing algorithms should either ignore everything that comes =20
after the 13th digit, or conclude that the NSS string in this =20
particular URN is incorrect. A sophisticated algorithm should always =20
do the former when the thing added to the URN is <query>. To my =20
knowledge, no such algorithms exist yet.

There are namespaces such as urn:nbn where no generic rules for the =20
NSS parsing exist. It may be that such parsing rules can be developed =20
sub-sections of these namespaces (for instance: to the NBNs generated =20
in the National Library of Finland). In these cases, a last resort =20
parsing rule can be used, which is that the first character which is =20
not allowed in that particular namespace indicates the end of the URN. =20
And if the namespace does not have any rules that go beyond the URN =20
syntax specification as regards the allowed characters, RFC 2141 can =20
be used as the basis for parsing the URN.

To sum up, the short text section quoted above could be edited to this =20
form in the next version of RFC2141bis in order to reflect the reality =20
more closely:

URNs will often be embedded in metadata records or in structured text. =20
There the encoding will make it clear where the NSS ends, and =20
therefore this method of incorporating URNs is recommended. A special =20
case of this is the use of URNs as HTTP URIs to make them resolvable =20
in the present Internet.

When URNs are incorporated in plain text, reliable parsing of =20
namespace specific strings is possible only if the identifier system =20
has a well formed syntax (which specifies e.g. the length of the =20
string) and the parser is familiar with it. For instance, ISBN numbers =20
are either 10 or 13 digits long depending on the version of the ISBN =20
standard, and the parser must be able to recognize which type of ISBN =20
is being processed, and behave accordingly.

If NSS contains a <query>, parsing algorithms MUST ignore it. If NSS =20
contains a <fragment> or a local add-on, parsing algorithms SHOULD =20
behave in different ways depending on the namespace. In the ISBN =20
namespace the algorithms SHALL ignore anything that comes after the =20
ISBN itself, and MAY label the ISBN as erroneous. Some other =20
namespaces (and possibly even future versions of ISBN) may allow the =20
user of <fragment> or local add-ons for identification of fragments of =20
resources, in which case the parsing algorithms will know how to deal =20
with them.

If the identifier does not have a specified syntax, but its character =20
set is more limited than that allowed by the URN syntax, a URN has =20
certainly ended when an octet/character from the character set =20
excluded in that namespace is encountered. This method is not =20
reliable; NSS may have ended earlier if the characters following the =20
NSS and not excluded.

If the namespace does not have any limitations concerning the =20
character set, a URN has certainly ended when an octet/character from =20
the excluded character set (<excluded>) is encountered.This method is =20
not reliable: NSS may have ended earlier.

Please note that the character from the excluded character set is NOT =20
part of the URN.

Best regards,

Juha