Re: URL: Background and Requirements

Gomer Thomas wrote:
> 
> The WWW-TV interest group seems to be thrashing around a bit on
> the URL requirements issue.
> 
> Attached is an attempt to provide some background information for
> members of the interest group who may not be familiar with the
> digital TV (DTV) environment, and an attempt to formulate some
> URL requirements. 

Thanks for this requirements list.
Below some comments from my perspective.

Warner ten Kate.

--
Philips Research Labs. WY21 ++ New Media Systems & Applications
Prof. Holstlaan 4 ++ 5656 AA  Eindhoven ++ The Netherlands
Phone: +31 4027 44830
Fax:   +31 4027 44648    tenkate@natlab.research.philips.com


Gomer Thomas wrote:
> 
> All this leads to the following requirements for URL schemes for
> DTV environments:
>     - URLs must actually be URLs, not just URIs. Given a URL, it
> must be possible for a receiver to actually locate the resource,
> or conclude that it is not reachable. 

When leaving away the first sentence and when changing the remaining 
occurance of "URL" into "URI", I agree on this requirement. 

This allows all other occurances of "URL" to be changed in "URI", 
which, given this requirement, do not change the intended objective, 
but do relax the design space we are discussing.


>     - It must be possible for the resource referenced by a URL to
> be an entire program/event, or just a single component of a
> program/event.

Agree.


>     - It must be possible for a URL to contain an identification
> of the date(s) and time(s) when the resource is available, either
> through an explicit time designation, or through an event
> designation.

Disagree.
After storage (locally at home, or at an Internet server) the 
resource's location should remain resolvable. Another example, 
is the case where a resource's transmission is rescheduled, 
delayed, or repeated. It will become cumbersome to maintain 
such information with the URIs, which themselves are embedded 
in application documents. A level of indirection seems required 
(e.g. using event tables). Instructions like prefetching could 
be declared within the application.

I understand the requirement to be :
- Given the 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.


>     - The set of URL schemes for DTV should include audio/video
> streams and all of the data broadcast protocols endorsed by the
> ATSC Data Broadcast Specification.

Not sure I understand this one.
I understand we require one single URI scheme which works for any 
type of transport protocol, including the ones defined outside ATSC.


>     - A URL must be meaningful when interpreted from any of the
> following locations relative to the resource being referenced:
>         * From within the same elementary stream
>         * From within the same program
>         * From within the same transport stream
>         * From within a different transport stream received by
> the same receiver

These can be combined into: 
"From the same (broadcast) network"

>         * From an arbitrary location in the Internet

I propose to rephrase this requirement into
- A URI should be resolvable under any of the following network 
  access conditions:
  - TV Broadcast (DVB, ATSC, DSS, analog)
  - Internet
  - In Home/local storage
  - Other (future) networks
  The actual resource's retrieved content data may differ in terms 
  of content quality, performance, and edit version.


> The correct interpretation of this requirement is that a DTV
> receiver should be able to obtain an HTML page from any of the
                                       ^^^^^^^^^
The resource is not per se an HTML page.

> listed locations, and if the resource referenced by a DTV URL in
> that page is available to that receiver in the broadcast streams
> it can receive, it should be able to find the resource.
> 

Craig A. Finseth wrote:
> 
> I would also like to add one other requirement:
> 
>  - A URL must be invariant with respect to the normal range of
>    transport stream transformations.
> 

Agree. (See my relative-URI requirement below).


I like to add the following requirements:

- The URI scheme should comply with RFC 2396 + ...... 
  [to be completed; Philipp ?]

- The URI scheme must be compatible with solutions already adopted 
  in standardisation bodies such as ATSC, DVB, and DAVIC.

- The URI scheme should interoperate with existing access schemes, 
  like http (the proposed URI scheme, not per se the access protocol 
  it calls; it means that hierarchies in the URI scheme should map 
  as much as possible).
  This should assist seamless transitions when the client decides 
  to use another access protocol (and network).

- Ideally, the URI should support referencing various instantiations 
  of the same content (quality/compression ratio, versions/edits).
  (above, such difference in instantiation was the consequence of 
  using another network).

- The URI scheme should support hierarchies, such as to enable relative 
  referencing. Referencing a TV-program with all its associated
resources 
  through such relative URIs should enable flexible transition to
another 
  storage/transmission environment. 


I am not sure to what extent all requirements can be met. Therefore, 
I used the wording 'should' iso. 'must'. In addition, unlike
conventional 
URI schemes the following exceptions are observed:

- The host is not necessarily a server identifyable through an
IP-address.
  (for instance the 'host' is a transport stream).

- The resource access and retrieval scheme is not necessarily IP-stack
based.


--END--

Received on Tuesday, 3 November 1998 08:18:11 UTC