URI Requirements

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


Message-ID: <D181361D7C86D011925700805FFE898E01971624@spybem01.nap.spyglass.com>
From: "Adams, Glenn" <gadams@spyglass.com>
To: "'tenkate@natlab.research.philips.com'" <tenkate@natlab.research.philips.com>
Cc: www-tv@w3.org
Date: Tue, 10 Nov 1998 11:28:22 -0600
Subject: 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.