Message-Id: <36495A69.email@example.com> Date: Wed, 11 Nov 1998 10:35:37 +0100 From: Warner ten Kate <firstname.lastname@example.org> To: "Adams, Glenn" <email@example.com> Cc: firstname.lastname@example.org Subject: Re: URI Requirements Glenn, Thanks for your comments. Adams, Glenn wrote: > > 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. > At the level of *this* requirement, I don't care. The information has to be made available somehow, that is, in a standardized way. At the level how to fulfill the requirement, I don't expect the former way will offer us a satisfying solution, a.o. because of requirements related to your signaled http compatibility. So, implicitly I am thinking of the second solution: introduce a level of indirection. I agree, SDP, CDF etc. are typical Web formats to use. In TV Broadcast environments I am thinking of something like the Event Information Table (EIT) defined in ETS 300 468 (DVB-SI). > 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? > Good point. Yes, I was thinking of those as well, but didn't went into them in detail. Maybe we should. Can you enumerate what's there in HTTP ? Wrt. the two you mention: content-encoding: I thought this part of the 'quality/compression ratio', but I agree it is something else. I have added it to those enumerations (I'll wait with posting the update a few days). Note, however, that within a TV Broadcast environment there is only one content-encoding, by standard. language: I think this is in the requirements implicitly. It may need some more attention; I don't think so, though. Do you have suggestions for an additional requirement? This is the way how I think language is in the requirements: If the URI refers to a complete service (TV program), the default language is to be used. "Default" may be influenced by the user settings. The broadcast system itself configures, the URI only refers to the complete service. We also require a URI to be able to refer to a component in such a service. That includes all its various language streams. So, an application can manipulate language choice by using the set of URIs referring to those components. Warner.