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
- [urn] URNs are not URIs (another look at RFC 3986) John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Julian Reschke
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] URNs are not URIs (another look at RFC … Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Nottingham
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Graham Klyne
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] URNs are not URIs (another look at RFC … Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Scott Brim
- Re: [urn] URNs are not URIs (another look at RFC … John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Nico Williams
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Barry Leiba
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Mark Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Martin J. Dürst
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Tony Finch
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- [urn] R: [apps-discuss] URNs are not URIs (anothe… Maurizio Lunghi
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Larry Masinter
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Edward Summers
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Phillip Hallam-Baker
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Juha Hakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Svensson, Lars
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… jehakala
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… John C Klensin
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… SM
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Dale R. Worley
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson
- Re: [urn] [apps-discuss] URNs are not URIs (anoth… Henry S. Thompson