Re: [urn] Finalizing items from IETF 83

Juha Hakala <juha.hakala@helsinki.fi> Thu, 28 June 2012 06:17 UTC

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 1BEA911E8135 for <urn@ietfa.amsl.com>; Wed, 27 Jun 2012 23:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.999
X-Spam-Level:
X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qse3EmzVxM+g for <urn@ietfa.amsl.com>; Wed, 27 Jun 2012 23:17:49 -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 30DC511E8085 for <urn@ietf.org>; Wed, 27 Jun 2012 23:17:47 -0700 (PDT)
Received: from [128.214.91.90] (kkkl25.lib.helsinki.fi [128.214.91.90]) by smtp-rs1.it.helsinki.fi (8.14.4/8.14.4) with ESMTP id q5S6HiC7029269 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NOT) for <urn@ietf.org>; Thu, 28 Jun 2012 09:17:45 +0300
Message-ID: <4FEBF708.9030604@helsinki.fi>
Date: Thu, 28 Jun 2012 09:17:44 +0300
From: Juha Hakala <juha.hakala@helsinki.fi>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.5) Gecko/20120605 Thunderbird/10.0.5
MIME-Version: 1.0
To: urn@ietf.org
References: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us>
In-Reply-To: <234FA8E3-C00D-4DA9-AD6C-41A3AC2548E4@hxr.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [urn] Finalizing items from IETF 83
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Revisions to URN RFCs <urn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/urn>, <mailto:urn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/urn>
List-Post: <mailto:urn@ietf.org>
List-Help: <mailto:urn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/urn>, <mailto:urn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jun 2012 06:17:50 -0000

Hello,

Concerning this:

On 26.6.2012 19:10, Andy Newton wrote:
> All,

> Second, at IETF 83 Leslie Daigle proposed removing the fragment language from 2141bis and placing it in a separate draft to be moved forward as an Experimental RFC. If you have objections to this approach, please let us know (again, before July 13).

I have an objection, but the fragment related sections of RFC2141bis 
must be made more clear.

The terms and conditions governing the fragment use are on the one hand 
technical, and on the other hand identifier system dependent. From 
technical point of view, fragments are part of the URI but they are not 
part of the NSS. From identifier system point of view, fragments are 
only applicable when a) the identifier system covers only manifestations 
and b) single manifestation of a resource only gets one identifier, 
which is never re-assigned.

In practice, this means that fragments are not applicable if the 
identifier covers immaterial works (like International Standard Text 
Code). Also, fragments cannot be used if the identifier covers multiple 
manifestations (for instance International Standard Serial Number 
applies to the entire journal). But fragments can be used with e.g. 
ISBNs since each ISBN is assigned to single manifestation of a book, 
such as PDF or XML version.

Since fragment is not part of the namespace specific string, a user who 
for instance wants to cite a certain paragraph of an e-book may add a 
fragment to the existing URN:ISBN of the book in order to provide a 
persistent link to the paragraph (assuming that the e-book is structured 
in such a way that this is possible).

When an e-book is migrated to another file format in order to preserve 
it, then according to the ISBN user guide the new version of the book 
must get another ISBN. Any identifier system which allows identification 
of multiple manifestations with a single identifier is not applicable 
for fragment use.

Depending on what the list attendees agree on, we may place a text to 
the above effect into rfc2141bis or into an experimental document. But I 
hope that RFC2141bis will say at least that fragments are not part of 
the NSS but they can be used in those namespaces which specifically 
allow that.

Best regards,

Juha

>
> -andy
> (obviously over-paid co-chair).
> _______________________________________________
> 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