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

Received on Thursday, 29 October 1998 17:21:49 UTC