[URN] required reading
Leslie Daigle <leslie@Bunyip.Com> Tue, 30 June 1998 18:19 UTC
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id OAA28372 for urn-ietf-out; Tue, 30 Jun 1998 14:19:54 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id OAA28367 for <urn-ietf@services.bunyip.com>; Tue, 30 Jun 1998 14:19:49 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id OAA01301 for urn-ietf@services; Tue, 30 Jun 1998 14:19:48 -0400 (EDT)
Received: from localhost (leslie@localhost) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id OAA01298 for <urn-ietf@bunyip.com>; Tue, 30 Jun 1998 14:19:47 -0400 (EDT)
Date: Tue, 30 Jun 1998 14:19:46 -0400
From: Leslie Daigle <leslie@Bunyip.Com>
To: urn-ietf@bunyip.com
Subject: [URN] required reading
Message-ID: <Pine.SUN.3.95.980630135713.29574G-100000@mocha.bunyip.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-urn-ietf@Bunyip.Com
Precedence: bulk
Reply-To: Leslie Daigle <leslie@Bunyip.Com>
Errors-To: owner-urn-ietf@Bunyip.Com
Before _anyone_ posts anything further on this thread (which has morphed itself into the "whydon'twehaverelativeURNs" thread), read: http://www.ietf.org/internet-drafts/draft-fielding-uri-syntax-03.txt (the latest draft of the URI syntax, including relative references) ftp://ftp.isi.edu/in-notes/rfc2276.txt Architectural Principles of Uniform Resource Name Resolution (i.e., the whole overview of what we think we're doing) ftp://ftp.isi.edu/in-notes/rfc2168.txt Resolution of Uniform Resource Identifiers using the Domain Name System (i.e., not just what the proposed IETF namespace does, but what can be done with our one proposed RDS). Too many of the arguments presented here have been based on an extrapolation of assumptions based on exposure only to the IETF namespace document, and/or a faulty understanding of the URI relative syntax handling. Let's review the group's position on relative URNs, and the use of "/" in a URN: . To say we "do relative URNs", we would have to understand how to make it work (while preserving the characteristics of URNs, such as persistence, etc) for ALL URNs in all namespaces. We have said that we don't yet know how to do that, and nothing presented to date in this current instantiation of this thread suggests we have learned otherwise. . We have said that, in anticipation of one day understanding that, and in order not to collide unnecessarily with URI schemes that do use hierarchies, we will not use "/" in an unescaped fashion in URNs. . We have also said that individual namespaces may elect to describe relative referneces using a hierarchical syntax of their choice. This does not allow abbreviated document references, but it does still permit the expression of relationships and namespace-specific software can make use of it. Furthermore, there has been work done (and there is still effort to refine it) to ensure that the expression of relative URIs in the defining syntax document makes it clear that a relative reference is only useful, within a document, if the defined "base" URI (see the syntax document to learn how to derive that) is of a scheme that supports relative references. I.e., doing an N2R that has relative references in it will leave you out in the cold, unless there is an explicit base URI transmitted in the transaction (e.g., within the HTML, HTTP exchange, whatever), but if you do an N2L and then resolve the URL, you are in fact still dealing with relative references against a URL. This may yet give you problems if the URL you used was not the one anticipated in writing the relative reference, but that's a URL problem, not a URN one. I.e., as Keith and Larry's exchange underscored, the problem is _only_ when you have extra-document references, not governed by the URI relative reference rules. Keith asked whether or not it is worth casting into question URNs' ability to provide persistent references in order to support this case. Anything I've seen suggests it comes back to point #1 -- we don't yet understand well enough how to do these across _all_ URN namespaces. I know there are people who disagree with this, but it's the considered opinion of this working group. Again -- read the documents. Leslie. ---------------------------------------------------------------------------- "The nice thing about reality Leslie Daigle is that there are so many versions to choose from." Bunyip Information Systems -- ThinkingCat (514) 875-8611 leslie@bunyip.com ----------------------------------------------------------------------------
- Re: [URN] URN required reading & a modest proposal Leslie Daigle
- [URN] URN required reading & a modest proposal Larry Masinter
- [URN] required reading Leslie Daigle