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.

Received on Wednesday, 11 November 1998 04:35:46 UTC