Re: URL: Background & Reqs (ASCII)
From: Gomer Thomas (gomer@lgerca.com)
Date: Thu, Oct 29 1998
Message-ID: <3638EA5A.2AAC9900@lgerca.com>
Date: Thu, 29 Oct 1998 17:21:14 -0500
From: Gomer Thomas <gomer@lgerca.com>
To: fin@finseth.com
CC: www-tv@w3.org
Subject: Re: URL: Background & Reqs (ASCII)
Craig,
Thanks for the encouragement.
I agree with your point about non-ATSC, non-DVB systems.
Pre-loading will probably present a problem if an explicit date/time range is
given. It may present less of a problem when an event_id is given, since whatever
mechanisms are endorsed by T3/S13 and/or DASE to deal with this problem in the
course of ordinary TV watching will be available. (As you probably know, this issue
has received quite a bit of discussion in T3/S13 and in the DASE end-to-end group.)
Your point about invariance of the URL was intended to be implicit in my
requirements on the ability of a DTV receiver to resolve the URL, but I agree that
it should be made explicit.
Gomer
Craig A. Finseth wrote:
> I think that you did an excellent job of summarizing the overall issues.
>
> I do have a couple of refinements to points that you made.
>
> ...
> To complicate things further, when a program is picked up by a
> cable or satellite operator and rebroadcast, nearly every single
> one of the identifiers for the program may be changed -- RF
> frequency, ts_id, program_number, major-minor channel number,
> source_id, packet ids, possibly even association tags. Proably
> the channel name will stay the same.
>
> It is also possible that the data transmission will be shifted in time
> relative to program content. In other words, some systems may _rely_
> on presend/caching rather than real time transmission.
>
> ...
> The ATSC Data Broadcast Specification (from T3/S13 subcommittee)
> specifies a number of different protocols for including data in
> an MPEG-2 broadcast stream:
> - DSM-CC bounded data carousels
> - DSM-CC unbounded data carousels
> - streaming data in PES packets
> - IP or other protocol datagrams encapsulated in PES or TS
> packets
> - piped data in TS packets
> ...
>
> Also, many systems currently in use are non-ATSC or DVB. It is
> desirable for new designs to be usable on the range of existing
> systems. Thus, too-heavy reliance on selected protocol stacks is not
> good.
>
> ...
> 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. (Note that locating the
> resource may require intermediate steps, analogous to a DNS
> lookup on the Internet. ATSC T3/S8 document 253, URL Mapping,
> submitted 26 Feb, 1998, by General Instrument, is a step in this
> direction, but does not quite solve the problem.)
> Agreed.
>
> - 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.
> Agreed.
>
> - 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.
> This items gets complex when pre-loading is involved.
>
> - 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.
> Agreed.
>
> - 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
> * From an arbitrary location in the Internet
> Agreed, with a caveat on the last ones that they device have access
> to the transport stream.
>
> The correct interpretation of this requirement is that a DTV
> receiver should be able to obtain an HTML page from any of the
> 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.
>
> I would also like to add one other requirement:
>
> - A URL must be invariant with respect to the normal range of
> transport stream transformations.
>
> Craig A. Finseth craig@finseth.com
> USSB cfinseth@ussb.com (coming)
> 3415 University Ave, Suite 201 +1 651 659 7162
> St Paul MN 55114 +1 651 646 8896 fax
> USA http://www.ussb.com
> A ship is safe in a harbor, but that's not what a ship is for--Adm Grace Hopper
--
Gomer Thomas
LGERCA, Inc.
40 Washington Road
Princeton Junction, NJ 08550
phone: 609-716-3513
fax: 609-716-3503