Re: URL: Background and Requirements

Gomer Thomas wrote:
> 

> I'm not sure I understand your point about changing the term URL to URI. As
> I understand it, the key difference between a URI and a URL is that a URI
> is just an identifier of a resource, whereas a URL is a URI which actually
> allows the location of the resource to be determined. Perhaps I am not
> understanding this correctly.

I am not very literate either, reading RFC 2396 may help, 
RFC 1630 also provides some backgrounds. I understand a URI 
to be the more general abstraction from URL and URN. All three 
allow the location of the resource to be determined. The URL 
is explicit in that; it points to one single location. The URN 
is indirect; it requires a naming service to resolve the location(s).

My proposed change in the requirements allows us to look for 
solutions which enable a single resource to be retrieved from 
multiple locations. By that change I am not requiring that 
such should be the case, but I am allowing it. Your requirement 
excludes that solution.

We both require that the location must be determined by 
the URI/L, which is formulated in the second sentence of 
the original requirement.


> 
> I don't agree with your comments about home/local servers, if I understand
> them correctly. When I download a file from an Internet server and store it
> on my local disk, the URL needed to reference the copy on my disk is
> different from the URL needed to reference the original copy on the
> Internet server. Similarly, if I record the 6 o'clock news from channel 5
> and store it on my local disk, I would expect that the URL needed to
> reference the local copy on my disk would be different from the URL needed
> to reference the original broadcast. Aside from the difference in location,
> the new copy is now available to me at any time, whereas the original
> broadcast was only available to me at a specific date-time.
> 

That's the more general problem I would like to tackle.
Likely we have a misunderstanding. Maybe the following 
examples help.

Assume there is a HTML document (document A) containing all 
kind of links to other HTML documents (B). Some of them (B) 
get downloaded on your local disc, some not. The URLs in the
document A are referencing the original B Web-site, and some 
mechanism is required to update the URLs in document A. 

[Altough we are talking about requirements, I guess this can 
partly be solved by using relative-URLs; the subtrees are 
required to remain identical, and the issue remains wrt. 
the base-URL.]

Now consider the case that document A is transmitted in a 
broadcast channel, together with the documents B. The URLs
in document A contain the information when documents B 
are "on the air". By one or another reason the broadcast 
get rescheduled. Who is taking care that the URL information
in document A is adapted (and how is he doing that) ?
And, indeed, when all documents are stored on my local disc,
how do I get rid of the timing information in the URLs ?

I agree that the content stored on your local disc is at 
another location than the original one. How do we inform 
the application document using that content about the change ?

I think we need both an URL scheme which points to a specific 
location, as some additional scheme which creates a level of 
indirection and enables to solve the type of problems I described.

[Expanding the caching strategy, as described by Glenn Adams, 
to persistent storage (VCR) is interesting, and generates, 
a kind of implicit level of indirection: first look at your 
VCR than in the broadcast stream. There is, however, not a way 
to manage explicitly that 'indirection' scheme. For example, 
I am not sure how it expands if multiple storage media (camcorder) 
connected to an in-home network are involved. What are the (implicit)
precedence rules ? Are all devices on the network to be checked 
if they contain the data requested (non-expired) ? Does it imply 
that during the original broadcast my user agent also has to check 
all my local storage devices at the in-home network ?]


Warner.

Received on Tuesday, 3 November 1998 12:51:19 UTC