Re: [urn] URNs are not URIs (another look at RFC 3986)

worley@ariadne.com (Dale R. Worley) Thu, 17 April 2014 19:48 UTC

Return-Path: <worley@ariadne.com>
X-Original-To: urn@ietfa.amsl.com
Delivered-To: urn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29621A0054 for <urn@ietfa.amsl.com>; Thu, 17 Apr 2014 12:48:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5dFLwHKJpfp for <urn@ietfa.amsl.com>; Thu, 17 Apr 2014 12:48:34 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:56]) by ietfa.amsl.com (Postfix) with ESMTP id 0E4161A0011 for <urn@ietf.org>; Thu, 17 Apr 2014 12:48:33 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta06.westchester.pa.mail.comcast.net with comcast id r1sf1n0070vyq2s567oWll; Thu, 17 Apr 2014 19:48:30 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id r7oV1n00R1KKtkw3R7oVmQ; Thu, 17 Apr 2014 19:48:30 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3HJmTLr005064 for <urn@ietf.org>; Thu, 17 Apr 2014 15:48:29 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3HJmTVr005063; Thu, 17 Apr 2014 15:48:29 -0400
Date: Thu, 17 Apr 2014 15:48:29 -0400
Message-Id: <201404171948.s3HJmTVr005063@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: urn@ietf.org
In-reply-to: <001976FFC9FE8FFCAA2E7990@JCK-EEE10> (john-ietf@jck.com)
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <CAMm+Lwia99RdyO4RFScSwCaVHLsr_BRzmXK18eUoxGFti79Vog@mail.gmail.com> <001976FFC9FE8FFCAA2E7990@JCK-EEE10>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1397764110; bh=i3KXQsVjdeXCbtTz6XpETSmVbXBiQ2ajobikJui7i4w=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=TXAK10qMOI/8jUxSjvZVX4qePuf6YFyzrYuN7XtMixxU7T0bFPxcpJa8azOaCk87p Yjr/dW/j2JnB6UBQjEAxVtKLe+laLA/nzJ0pkCfd6MF0LEIQisTPQUJ72RyVSyT2Bc UN2srJ91mSmT+DixAfI3g/nhBni9W4RoOx42VBIb4NYn2nNkAWxUj91QcYM9aFWoHn mfEs1rmqqsArwpC5awar6pwDP+zHf+Qrmdmtj3nbUj1Bnz4ZPAsGoJDnErvDIKPcym /XxXKIYMtcqvRpGq0GfHjDRbWExc+15nS5af7ndzdE4N9i/OVTuoLenhtmMPYeEypn tClaHsAtuIACA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/UFuZigLvCXD1WC37geXArv6RqzE
Subject: Re: [urn] URNs are not URIs (another look at RFC 3986)
X-BeenThere: urn@ietf.org
X-Mailman-Version: 2.1.15
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, 17 Apr 2014 19:48:36 -0000

I think some of the questions that we're dealing with are fairly deep
and they're not being addressed well.

What is really under debate is overhauling URNs.  That is, producing a
a new syntax (and possibly semantics) of URNs that is not necessarily
upward-compatible with RFC 2141.

But what I'm not seeing is a discussion of the factors that would
drive such a decision:

- Why is the current framework inadequate?

- How will use of URNs of the new type coexist with URNs of the old
  type?

In particular, I've seen repeated statements that the current
framework is inadequate for the future development of URNs, but I
haven't seen even a summary of the discussion, nor any pointer to the
record of the discussion discussion itself, nor how to participate in
that discussion.

Dale