Message-ID: <D181361D7C86D011925700805FFE898E019715F8@spybem01.nap.spyglass.com> From: "Adams, Glenn" <email@example.com> To: "'Henning Timcke'" <firstname.lastname@example.org> Cc: www-tv <email@example.com> 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:firstname.lastname@example.org] 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:email@example.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:firstname.lastname@example.org] 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.