RE: URL: Background and Requirements

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

Message-ID: <D181361D7C86D011925700805FFE898E019715F8@spybem01.nap.spyglass.com>
From: "Adams, Glenn" <gadams@spyglass.com>
To: "'Henning Timcke'" <henning.timcke@werft22.com>
Cc: www-tv <www-tv@w3.org>
Date: Tue, 3 Nov 1998 12:11:48 -0600 
Subject: RE: URL: Background and Requirements


While I don't endorse all of the details of their implementation, the
ATVEF folks have developed an "HTTP like" unidirectional protocol which
essentially permits the use of the MIME-like payload and header (as well
as caching) semantics of HTTP.

BTW, your equation of user agent = browser = parser = presentation
engine = viewer = client is incorrect in general. In the context of
IETF, "user agent" is the most common term employed for a protocol
client operated by a human end-user. A protocol client may be found in
robot agents as well as proxy and gateway servers, which would not be
constitute user agents. Furthermore, a user agent may not necessarily
take the form of a viewer: one can have an audio-only user agent that is
a protocol client for audio data. Parsing, formatting, and presenting
are merely sub-functions of a viewer user agent and are separate from
the protocol client itself.

		-----Original Message-----
		From:	Henning Timcke
[mailto:henning.timcke@werft22.com]
		Sent:	Tuesday, November 03, 1998 11:36 AM
		To:	'Adams, Glenn'; 'Gomer Thomas'; Warner ten Kate
		Cc:	www-tv
		Subject:	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.