Re: URL: Background and Requirements

Gomer Thomas wrote:
> 

Thanks.

Seems to me we have the same understanding in what a URI and 
what a URL is.

I also think we agree that the requirements improve by rewording 
URL into URI. The objective to locate the identified resource remains.


> In section 1.2 it states "The term 'Uniform Resource Locator' (URL) refers to the
> subset of URI that identify resources via a representation of their primary
> access mechanism ..." 

I understand that, that other than 'primary' mechanisms are excluded, 
which is something I don't want to exclude a-priori in our requirements.
(I am not saying we should not use URLs.)


> Further down it mentions that "... both DNS and HTTP are
> typically used to access an 'http' URL's resource  ..." This implies to me that
> the term URL includes the usual form we find in HTML pages, based on an Internet
> domain name. 

Agree, that 'form we find in HTML pages' comforms the URL syntax and
semantics.


> As you probably know, this does not necessarily resolve to a unique
> location, since a DNS server may return multiple IP addresses for a single
> Internet domain name. Sometimes these refer to multiple network interfaces on the
> same host, but sometimes they refer to separate hosts, for example in the case of
> mirrored servers.
> 

Sorry, I didn't know. I knew RDS (Resolver Discovery Service) was doing 
that, using DNS [RFC 2168]. From the 2168-Abstract:

   "Uniform Resource Locators (URLs) are the foundation of the World
Wide
   Web, and are a vital Internet technology. However, they have proven
   to be brittle in practice. The basic problem is that URLs typically
   identify a particular path to a file on a particular host. There is
   no graceful way of changing the path or host once the URL has been
   assigned. Neither is there a graceful way of replicating the resource
   located by the URL to achieve better network utilization and/or fault
   tolerance. Uniform Resource Names (URNs) have been hypothesized as a
   adjunct to URLs that would overcome such problems. URNs and URLs are
   both instances of a broader class of identifiers known as Uniform
   Resource Identifiers (URIs)."

I thought DNS provides you with a host-name to IP-address mapping 
(and v.v.); a mirror is using another host-name. Isn't http providing 
a re-direction service ?

Anyhow, this name vs. location (IP-address) in the host-part of 
the URL provides the type of extra abstraction I am after with 
my URL2URI substitution for the complete URI/L.


> Further down it in section 1.2 it states "A URN differs from a URL in that it's
> [sic] primary purpose is persistent labeling of a resource with an identifier."

That's why to me it is an interesting candidate for our type of problem.


> Thus, there seems to be no intent that a URN (which is a subset of URI) provide
> any assistance whatsoever in locating the resource.

There are schemes how to resolve a URN into a URL, eg.. the RFC 2168.


> 
> Having said all that, I am in complete agreement with your intent that we should
> be allowed "to look for solutions which enable a single resource to be retrieved
> from multiple locations." I had never intended to exclude this possibility, and
> in fact the solutions which I have been considering do allow it. I cheerfully
> accept any changes to the wording of the requirements which make that more clear.

Thanks.
Btw. is somebody willing to edit and document a requirements list ? (you
?, Philipp?)

> 
> I think the solution to the problem of multiple interlinked documents getting
> moved to local storage lies in the use of relative URLs, as you suggest, together
> with some mechanism to adjust the base URL appropriately.
> 
> The solutions I have been thinking of handle the problem of rescheduled events. I
> will try to write up my ideas in this area as soon as I get a couple of other
> brush fires out of the way -- and as soon as we converge on the requirements
> (which seems to be very close to happening).
> 

Thanks again,
I am looking forward to your proposals,

Warner.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com

Received on Wednesday, 4 November 1998 08:59:03 UTC