Re: [urn] I-D Action: draft-saintandre-urn-example-00

Alfred Hönes <ah@TR-Sys.de> Thu, 16 August 2012 21:03 UTC

Return-Path: <A.Hoenes@TR-Sys.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 1FFBF21F867F for <urn@ietfa.amsl.com>; Thu, 16 Aug 2012 14:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.583
X-Spam-Level:
X-Spam-Status: No, score=-98.583 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, 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 xyqF9ab9e4gy for <urn@ietfa.amsl.com>; Thu, 16 Aug 2012 14:03:31 -0700 (PDT)
Received: from TR-Sys.de (gateway.tr-sys.de [213.178.172.147]) by ietfa.amsl.com (Postfix) with ESMTP id D423121F867E for <urn@ietf.org>; Thu, 16 Aug 2012 14:03:28 -0700 (PDT)
Received: from ZEUS.TR-Sys.de by w. with ESMTP ($Revision: 1.37.109.26 $/16.3.2) id AA214570894; Thu, 16 Aug 2012 23:01:34 +0200
Received: (from ah@localhost) by z.TR-Sys.de (8.9.3 (PHNE_25183)/8.7.3) id XAA08756; Thu, 16 Aug 2012 23:01:33 +0200 (MESZ)
From: Alfred =?hp-roman8?B?SM5uZXM=?= <ah@TR-Sys.de>
Message-Id: <201208162101.XAA08756@TR-Sys.de>
To: moore@network-heretics.com
Date: Thu, 16 Aug 2012 23:01:32 +0200 (MESZ)
In-Reply-To: <502CDE74.4050400@network-heretics.com> from Keith Moore at Aug "16, " 2012 "07:50:12" am
X-Mailer: ELM [$Revision: 1.17.214.3 $]
Mime-Version: 1.0
Content-Type: text/plain; charset=hp-roman8
Content-Transfer-Encoding: 7bit
Cc: urn@ietf.org
Subject: Re: [urn] I-D Action: draft-saintandre-urn-example-00
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, 16 Aug 2012 21:03:32 -0000

(no hat)

On 08/16/2012, Keith Moore wrote:
> On 08/14/2012 09:59 AM, Andy Newton wrote:
>> Given that URNs are suppose to have permanence or persistence or
>> whatever we are calling it today and a resolution mechanism, this
>> desire to shoehorn identifiers that need to qualify as a URI into the
>> URN system might be wrong. An identifier that must be a URI does not
>> necessarily need or have all the properties to be a URN. Just an
>> observation.
> +1
>
> URNs were intended to be _resource names_, i.e. names of resources
> rather than merely unique identifiers.  The expectation was that such
> resources would generally be at least potentially accessible over the
> network, and that it would be possible to resolve such names to resource
> locations.   Everyone agreed that it should be possible to assign URNs
> to resources that were not resolvable, or at least not resolvable for
> the time being.  But the idea that URNs are appropriate for use whenever
> someone needed a unique non-resolvable identifier that qualifies as a
> URI, always has struck me as bizarre and contrary to the intended
> purpose of URNs.
>
> Keith

+1 (for both statements)

I already have responded similarly to the seminal email wrt this topic
(by Julian) that has motivated the creation this I-D (by PSA).

The above notes seem to be properly backed the following excerpts
from RFC 1737, "Requirements for Uniform Resource Names",
Section 2, "Requirements for functional capabilities":

|      ...
|      It is intended that the lifetime of a URN be permanent.
|      ...
|
|      URNs can be assigned to any resource that might conceivably
|      be available on the network, for hundreds of years.
|      ...

IMO, the concepts of "example URNs" and "testing URNs" seem to be
fundamentally incompatible with these requirements.  For the latter,
rapid software development for testing of namespace management and
resolution systems can be furthered by "early reservation/assignment"
of URN Namespace IDs by IANA (as soon as urn-nid mailing list and
expert review "thumbs up" is obtained for a new URN Namespace proposal.

Best regards,
  Alfred.


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