Re: URL: Background and Requirements

I agree with most of your comments. In particular, I agree that DVB, DSS,
analog, etc., protocols should be accommodated as well as ATSC protocols,
and I agree that all resources are certainly not HTML pages. (My statement
about HTML pages should have had the words "for example" in it somewhere.)

I'm not sure I understand your point about changing the term URL to URI. As
I understand it, the key difference between a URI and a URL is that a URI
is just an identifier of a resource, whereas a URL is a URI which actually
allows the location of the resource to be determined. Perhaps I am not
understanding this correctly.

I don't agree with your comments about home/local servers, if I understand
them correctly. When I download a file from an Internet server and store it
on my local disk, the URL needed to reference the copy on my disk is
different from the URL needed to reference the original copy on the
Internet server. Similarly, if I record the 6 o'clock news from channel 5
and store it on my local disk, I would expect that the URL needed to
reference the local copy on my disk would be different from the URL needed
to reference the original broadcast. Aside from the difference in location,
the new copy is now available to me at any time, whereas the original
broadcast was only available to me at a specific date-time.

Gomer Thomas

Warner ten Kate wrote:

> 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--



--
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
phone: 609-716-3513
fax: 609-716-3503

Received on Tuesday, 3 November 1998 10:03:15 UTC