AW: URL: Background and Requirements

So the user agent is the same as the browser as the parser as the presention engine as the viewer as the client.
I agree to what is written below in general, except: can anybody explain how functionality similar to HTTP 1.x should work without any inter-action ? Should there be a minimal ineraction intelligence implemented in the user agent who is the same as the browser as the parser as the presention engine as the viewer as the client ?

Henning
Ideen Werft22 GmbH
-----Ursprüngliche Nachricht-----
Von:	Adams, Glenn [SMTP:gadams@spyglass.com]
Gesendet am:	Dienstag, 3. November 1998 17:31
An:	'Gomer Thomas'; Warner ten Kate
Cc:	www-tv
Betreff:	RE: URL: Background and Requirements



		-----Original Message-----
		From:	Gomer Thomas [mailto:gomer@lgerca.com]
		Sent:	Tuesday, November 03, 1998 10:03 AM
		To:	Warner ten Kate
		Cc:	www-tv
		Subject:	Re: URL: Background and Requirements


		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.
		
The storage of content for reuse in a temporally constrained manner
should be
considered in the context of user agent caches. Clearly, the end user
will not
be explicitly retaining this content under most (perhaps all)
circumstances; rather
the user agent will be implicitly retaining it in its cache for
transient reuse.

The caching of such content is typically keyed upon the original URI,
usually
in an absolute URI form. In the present discussion, given that no return
channel
to a server would be expected, revalidation of cached content would not
be possible;
instead, content freshness would be computed based on explicit
expiration data
and served out of the cache on that basis. See section 13 (Caching in
HTTP) of
HTTP/1.1
<http://www.ietf.org/internet-drafts/draft-ietf-http-v11-spec-rev-05.txt
> , presently in Internet Draft form.

Given the semantics of caching and cache entry freshness, it is quite
reasonable to employ a URI in embedded content (e.g., in HTML) that
references content that changes as programs change. The expiration times
of cached content would be keyed to the surrounding broadcast content.
Furthermore, if some content were pushed with a given expiration time
and
it was later determined that the content should be replaced or the
expiration
time updated, then new content could be pushed through to the cache
which
updates either its content, its freshness data, or both.

Regards,
Glenn Adams
Spyglass, Inc.

Received on Tuesday, 3 November 1998 12:15:59 UTC