AW: URI Requirements

I think the URI Requirements Document is good work allowing all the potential of URX to expand.
"The host is not necessarily a server identifyable through an IP-address. For instance, the 'host' is a transport stream. "
To equal a stream with a host is a brilliant idea:)
"The resource access and retrieval scheme is not necessarily IP-stack based."
Okay

The resource's availability implicitly depends on, or at least relates to, a transmission schedule. 

I agree to what is stated above (Warner) and below (Glenn), except I think it is not necessary to decide that the information to resolve such a determination should be present in the URI directly or not, I think it is of importance to 
acknowledge that such determination has to be made explicit: from my personal point of view, this means to hook a time and timing-model (transmission schedule) to either the protocol or the URX.
I believe this model should be *hookable* to diffrent approaches. 
I will study the timing models in MPEG-4, in SMIL, in HTML+Time and in what Warner (Thank you !) has compiled in http://lists.w3.org/Archives/Public/www-tv/1998OctDec/0107.html . And after I have reviewed all this, I'll be back and offer for discussion what I have found. I have in mind the current URX and XML specs can do it all, when there is a timing model independed from URX and XML.
Henning Timcke
Ideen Werft22 GmbH

-----Ursprüngliche Nachricht-----
Von:	Adams, Glenn [SMTP:gadams@spyglass.com]
Gesendet am:	Dienstag, 10. November 1998 18:28
An:	'tenkate@natlab.research.philips.com'
Cc:	www-tv@w3.org
Betreff:	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.

2.	Regarding:

		A URI should be resolvable under any of the following
network access conditions: 
		...
		The actual resource's retrieved content data may differ
in terms of content quality, performance, and edit version.

	and

		Ideally, the URI should support referencing various
instantiations of the same content (quality/compression ratio,
versions/edits). 

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?

Glenn Adams
Spyglass, Inc.

Received on Tuesday, 10 November 1998 12:59:40 UTC