[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
----------------------------------------------------------------------------