Message-ID: <01BE0CDB.D1F7C640@marketing.aart.ch> From: Henning Timcke <firstname.lastname@example.org> To: "'Adams, Glenn'" <email@example.com>, "'firstname.lastname@example.org'" <email@example.com> Cc: "firstname.lastname@example.org" <email@example.com> Date: Tue, 10 Nov 1998 18:56:25 +0100 Subject: 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:firstname.lastname@example.org] Gesendet am: Dienstag, 10. November 1998 18:28 An: 'email@example.com' Cc: firstname.lastname@example.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.