Date: Fri, 7 Oct 1994 16:17:21 +0100 (BST)
From: "Jon P. Knight" <J.P.Knight@lut.ac.uk>
Subject: Re: Why URN is a subset of URL
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
In-Reply-To: <9410070349.aa17724@paris.ics.uci.edu>
Message-Id: <Pine.3.05.9410071522.G19755-d100000@suna>
On Fri, 7 Oct 1994, Roy T. Fielding wrote:
> So, at this point I'd like to ask:
>
> Is it a requirement of any URN definition (for the purpose of IETF)
> that a URN be capable of being used to seek out and determine a
> location of the Resource identified by the URN?
>
> The answer is yes, according to the "Requirements for Uniform Resource Names"
> <draft-ietf-uri-urn-req-00.txt>, and thus all IETF URNs will also be Locators.
Erm, I read the answer as no (from <draft-ietf-uri-urn-req-00.txt>):
It is strongly recommended that there be a mapping between the
names generated by each naming authority and URLs. At any
specific time there will be zero or more URLs into which a
particular URN can be mapped.
The thing to note there is the ``zero''; the IETF URN requirements
specifcally appear to allow URNs that DO NOT allow one to ``seek out and
determine a location of the Resource identified by the URN''. This could
well be the crux of the matter in this little discussion; a URN is just a
name. It just so happens that that name can _sometimes_ be used to yield a
resource by dereferencing it into a locator and then dereferencing that
locator into the target resource. A URL on the other hand, assuming its
valid, will always allow one to locate the resource (that being its
purpose after all).
[functional maths deleted]
OK, following the maths logic we can show that a document containing
URNs and URLs (an HTML document for example) is itself a Locator:
Let URL be the set of all functions L, such that
(1) L : url_string -> resource_instance
and let Browser be the set of all functions B (eg user choice, robot
search, etc), such that
(2) B : document_string -> url_string
Now, using the rules of function composition,
(3) B o L : document_string -> resource_instance
In other words, L(B(document_string)) -> resource_instance
Now, how many people would claim that all documents containing URLs
(and following the logic of the deleted maths, URNs) should be called
Locators? Hopefully nobody (otherwise I'm packing up my marbles and going
home as this discussion could go on forever :-) ). I'd like to be able to
spot when I should apply function B to string or function L or function N
or function C1. What happens for example if I apply L to a
document_string directly? Because I might if I can't tell a url_string
from a document_string.
> The moral of this story is that it is a bloody waste of everyone's time
> to define a syntax for IETF URNs which is separate from IETF URLs, and
> that if you desire to place some special significance on the acronyms,
> then we should resurrect the common syntax called "URI" such that the
> syntax is associated with URI instead of URL and we won't get into
> religious wars every time URNs and URLs are compared.
If all you're arguing is that IETF URLs and IETF URNs should have a
common syntax then fine; I've no problem with that (unless someone can
show a good reason why the IETF URN requirements would be broken by
accepting such a syntax. Any takers?). However, I'd still
like the ability to spot the difference between a URL and a URN as the
semantics of URNs are not (IMHO) a subset of the semantics of URLs.
Just like I like to be able to spot the difference between gopher and
http URLs.
> Since there is no technical reason to choose a separate syntax, there
> is no valid reason why this IETF working group should use a separate syntax.
Fair enough. As long as we all realise that this isn't the WWW syntax.
> If a URN is defined such that the syntax does
> not conflict with the IETF URL syntax of <scheme>:<scheme-specific-part>,
> then the current version of XMosaic (and many other WWW clients)
> is perfectly capable of accessing that resource, providing that some
> proxy gateway exists which can do the URN->URL resolution and return
> an HTTP redirect message. All the user has to do is define an environment
> variable called <scheme>_proxy which points to the gateway, e.g.
>
> setenv isbn_proxy http://gateway.ics.uci.edu:8080/
>
> and then all references of the form "isbn:anything" will result in the
> request
>
> GET isbn:anything HTTP/1.0
>
> being sent to port 8080 of gateway.ics.uci.edu. What the gateway returns
> is entirely up to the particular piece of software acting as the server
> on that machine and port. It may very well be an HTTP -> whois++ gateway.
This I like and I think is good reason why the _syntax_ of URLs and URNs
_should_ be the same, unless someone comes up with a better reason for
the contrary. However we must realise that the HTTP->whatever++ gateway
will not necessarily return the target resource or URLs to it given a
valid URN.
Bottom line; I don't care too much about the syntax as long as I can
differentiate a URN from a URL (well, as long as its not in perl :-) ).
If you don't need to then fine, but I think I will have to for some things
I'm doing. I reckon that's doable using the ``IETF URI syntax'' so I'm
happy. If anyone doesn't think so, say so NOW! Otherwise, lets get back
to the programme and get on with building the IIIA.
Jon
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon Knight, Research Student in High Performance Networking and Distributed
Systems in the Department of _Computer_Studies_ at Loughborough University.
* It's not how big your share is, its how much you share that's important *