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

worley@ariadne.com (Dale R. Worley) Fri, 09 May 2014 02:46 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 CBC991A0123 for <urn@ietfa.amsl.com>; Thu, 8 May 2014 19:46:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GQ3fwPq2N-YU for <urn@ietfa.amsl.com>; Thu, 8 May 2014 19:46:05 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 435641A0107 for <urn@ietf.org>; Thu, 8 May 2014 19:46:05 -0700 (PDT)
Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta14.westchester.pa.mail.comcast.net with comcast id zeXu1n0041ap0As5Eem0AJ; Fri, 09 May 2014 02:46:00 +0000
Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta22.westchester.pa.mail.comcast.net with comcast id zelz1n00K1KKtkw3ielzgB; Fri, 09 May 2014 02:46:00 +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 s492jwbX001203; Thu, 8 May 2014 22:45:58 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s492jvSj001202; Thu, 8 May 2014 22:45:57 -0400
Date: Thu, 08 May 2014 22:45:57 -0400
Message-Id: <201405090245.s492jvSj001202@hobgoblin.ariadne.com>
From: worley@ariadne.com
Sender: worley@ariadne.com
To: John C Klensin <john-ietf@jck.com>
In-reply-to: <71FCF3F23062A6AE7F8552C9@JcK-HP8200.jck.com> (john-ietf@jck.com)
References: <C93A34DBE97565AD96CEC321@JcK-HP8200.jck.com> <534BED18.9090009@gmx.de> <3D39F1AA700A179F3C051DE2@JcK-HP8200.jck.com> <534D3410.50607@ninebynine.org> <54ecc96adba240159cf624c54c507136@BL2PR02MB307.namprd02.prod.outlook.com> <952E89C207E59D25CD5953D6@JCK-EEE10> <358467E0-F2C0-4468-A099-BBAA4F5438D2@mnot.net> <FAB32F8D-4BE4-4E49-AE8E-022D322C3BCC@pobox.com> <11B3A42537CE2D687E206A34@JcK-HP8200.jck.com> <201404252110.s3PLAPM1031471@hobgoblin.ariadne.com> <71FCF3F23062A6AE7F8552C9@JcK-HP8200.jck.com>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1399603560; bh=hnbPrjHFRwl17a/30ilQBSaTml7OBHXjD4VENAD9krc=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=nhQYobEpy6QBo10sF3mBd42A7Gv+qD1cKsNzDM1g5iTTxA9KgkW3bDnmM1CMiWY9D Mq9Sbw0IhDjl7dwrOxYwXu1Zq5XzH2MyAbV8RmTF/vHFd/ZuwrBMr5iXRYegxGUwnj 7vK14LES12x55eQ14T6Vs+MDUQF2g0xJTrl9A4yiR1HPqL//LWmXtiIp4FwCzaQokQ 8Fcavz7K2l/QVlPDOWq8cZy7lP3xmccuYA+tBAuQZDY05cVdmNfqwMOUJNbwmUVTE+ YAuBmcq6KfMwYMlCpCk5iAasymLnu6Tl1t+S/MusPgsQcByzINzlkYlfXdhKY4Tvcd Osmc2T0yCSJgA==
Archived-At: http://mailarchive.ietf.org/arch/msg/urn/7LBT5y_eLcngicq1JOtkcYxCACQ
Cc: urn@ietf.org
Subject: Re: [urn] [apps-discuss] 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: Fri, 09 May 2014 02:46:07 -0000

> From: John C Klensin <john-ietf@jck.com>

> Because the query model of 3986 is, at least IMO, pretty closely
> tied to the interpretation of queries in http-style URLs, it is hard
> to make those distinctions except, perhaps, by kludge.

This is one a I don't understand.  As far as I can tell, the
constraint on the semantics of the query-part in RFC 3986 is:

   3.4.  Query

   The query component contains non-hierarchical data that, along with
   data in the path component (Section 3.3), serves to identify a
   resource within the scope of the URI's scheme and naming authority
   (if any).

In regard to the urn-scheme, in which URNs do not have naming
authorities, this seems to establish essentially no limitations.  It
says "identify a resource", but a "resource" could be *anything*.
That is, the meaning of the query-part is entirely up to the NID
registration.  In particular, a particular query-part value can be
defined to mean "fetch the metadata", because the metadata of a
resource can itself be considered a "resource", which is designated by
a URN containing a specific query-part value.  Similar definitions can
be established regarding other "forks" of a resource, and modifiers of
how the query/resolution process is to be executed.

Given that no NID defined the use of query-part, we could write a
single standard for query-parts in the urn-scheme that would apply to
all NIDs.

> It can be accommodated using use "?" syntax of 3986, but only by the
> use of some reserved keywords or other instances of horrible kludges.
> One or two such kludges were proposed to the WG.  I think it is
> accurate to report that they got no traction.

I'm not able to visualize how one could denote the "it" in this
sentence (whose meaning I do not clearly understand) by character
strings in a way in which the syntax of 3986 proves to be excessively
restrictive.  The 3986 syntax is a string from this character set:

   ALPHA / DIGIT
   / "-" / "." / "_" / "~" / "/" / "?" / ":" / "@"
   "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
   and %-escapes

I can't visualize a syntax for identifiers that is significantly more
accommodating -- with the large exception of changing to Unicode as
the underlying character set.  Although Unicode can be represented by
%-escapes, so we can cover even Unicode by having the user interface
translate to/from %-escapes.

Perhaps you know of a proposed modifier syntax (e.g., a way of
specifying a "fork" or specifying modification of the query/resolution
dynamics) that illustrates features that are difficult to implement
within the current syntax of query-part.

Of course, none of this deals with the fact that 2141 does not admit
query-part on urn-scheme URNs.  But solution of any of these problems
will almost certainly require some extension of 2141.

Dale