RE: URL: Background and Requirements

From: Adams, Glenn (gadams@spyglass.com)
Date: Tue, Nov 03 1998


Message-ID: <D181361D7C86D011925700805FFE898E019715F6@spybem01.nap.spyglass.com>
From: "Adams, Glenn" <gadams@spyglass.com>
To: "'Gomer Thomas'" <gomer@lgerca.com>, Warner ten Kate <tenkate@natlab.research.philips.com>
Cc: www-tv <www-tv@w3.org>
Date: Tue, 3 Nov 1998 10:30:40 -0600 
Subject: 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.