AW: URI Requirements

Craig, all
I intended and intend the development of an outside protocol to handle scheduling and topological issues.
What do you have in mind with:
The approach that makes sense to me is to use an outside protocol (the
EPG data) to resolve the date/time issues. 

Supposed such an outside protocol existed, what URI requirements
have not been listed here ?

What is your comment on the DTV URL Scheme of Thomas Gomer ?

respects

Henning
 


-----Ursprüngliche Nachricht-----
Von:	Craig A. Finseth [SMTP:fin@finseth.com]
Gesendet am:	Montag, 16. November 1998 20:01
An:	gadams@spyglass.com
Cc:	tenkate@natlab.research.philips.com; www-tv@w3.org
Betreff:	Re: URI Requirements

   1.	Under your recent URI requirements document, you have:

			   Given a URI, it must be possible for a receiver
   to determine the time period(s) within which the resource can be
   retrieved from the (also resolved) location. 

	   Do you intend by this that the information to resolve such a
   determination should be present in the URI directly? Or that in
   combination with some unspecified higher-level-protocol, e.g., SAP, SDP,
   etc., the URI may be used as a key to resolve such a determination?

	   If you mean the former, then this requirement goes beyond the
   standard semantics of, say, HTTP URLs, which have no intrinsic temporal
   validity outside of the scope of querying an origin server, etc., for
   the resource and being informed it is no longer present, etc.

I would suggest that this requirement is an attempt to reconcile the
differences between the nature of TV broadcasting (programs on a
schedule) with the web.

The approach that makes sense to me is to use an outside protocol (the
EPG data) to resolve the date/time issues.

   2.	Regarding:

		   A URI should be resolvable under any of the following
   network access conditions: 
		   ...
   In HTTP's interpretation of URIs, other resource variation axes are
   provided as well: language, content-encoding, etc. Do you envision these
   applying in this context? What other variation axes do you anticipate?

Most transfer protocols provide some mechanism to carry the header
information.  Thus, whatever versions (as named by headers) the
broadcaster desires can be sent.

Unlike the regular web, there is no negotiation phase: the broadcaster
makes the sole determination (based on indirect information such as
customer surveys) of what to send.

Bandwidth and cost factors will also come into play (:-).

Craig

Received on Monday, 16 November 1998 15:40:42 UTC