URL: Comments on TV URI reqs I-D

From: Gomer Thomas (gomer@lgerca.com)
Date: Tue, Nov 17 1998

Message-ID: <3651B308.B83CB8ED@lgerca.com>
Date: Tue, 17 Nov 1998 12:31:52 -0500
From: Gomer Thomas <gomer@lgerca.com>
To: www-tv <www-tv@w3.org>, End-to-end <e-e@toocan.philabs.research.philips.com>
Subject: URL: Comments on TV URI reqs I-D


Some clarifications/modifications which I think are needed to the
Internet-Draft on TV URI scheme requirements:

(1) The words "must" and "should" are being used with slightly
different meanings. We should state explicitly what those
meanings are.

(2) We should number the requirements for easy reference, rather
than just have a bullet list.

(3) The second requirement refers to "components" and "fragments"
of a program. We need to define what those terms mean. In my
original draft I used the word "component" to refer essentially
to an elementary stream in a DTV broadcast. It could also be used
to refer to the video track, audio track, or "extended data
track" (VBI line 21 encoded data) in an NTSC broadcast, I
suppose. I'm not sure what you mean by "fragments". Is that a
time segment of an event? -- for example an ad segment, or the
first quarter of a basketball game?

If that is what you mean, then the statement that fragments are
outside the scope will be somewhat controversial. In particular,
some members of DASE think that one should be able to reference a
commercial within an event, since advertisers may in some
circumstances want to publicize and point to the appearance of an
ad -- for example, the famous Apple Computer ad during the
SuperBowl a few years ago. My initial reaction was serious
skepticism about the utility and feasibility of doing this.
However, on thinking it over, I can see some value in it, and
maybe it not very difficult. See my comments in (4) below.

(4) In the fourth requirement we need to specify what kind of
time granularity is intended. In my mind there are three possible
levels of granularity: (A) event, (B) fragment (as described
above), and (C) tiny, where "tiny" refers to the precise time(s)
at which a resource such as an MPEG-2 frame or a JPEG file or an
HTML page is being broadcast.

We certainly want a TV URI to support time granularity at the
event level -- although in an ATSC context at least we may need
to add the event_id to the channel information in the VCT so that
it is possible to determine what event is currently showing
without relying on the EITs being kept 100% up to date in the
face of schedule shifts, etc.

I believe "fragments" should be handled by "URI References" as
described in section 4 of RFC 2396. I.e., they are not within the
scope of the URI proper, but they are accommodated by the overall
"URI reference" syntax. In the case of a TV URI, the fragment
syntax should support the use of either a byte offset (as would
be appropriate when the URI references an HTML page) or a time
offset (as would be appropriate when the URI references an
event). By allowing the time offset to be either a number or a
symbol, as is done with byte offsets, any arbitrary segment can
be referenced, even if the precise time offset is not known (as
would be the case with an ad in a sports contest, or the
half-time show in a football game). All that is needed is a way
to insert a segment name into the broadcast stream, for example
by defining a new optional Segment Name descriptor to go in the
inner descriptor loop of the VCT (in an ATSC context). This
descriptor would appear only during the segment.

We should definitely make it clear that "tiny" is outside the
scope of the URI.

(5) We need to clarify the seventh requirement, on interpreting a
URI "from any of the following locations". The DASE end-to-end
team was more or less uniformly confused about just what that
meant. Part of the problem may be that the term "TV broadcast
network" seems to have a different meaning in North America than
in Europe. Here it is usually interpreted to mean something like
NBC or PBS, consisting of a central organization and a number of
local affiliate stations. In Europe I gather it is usually
interpreted to mean the entire collection of terrestrial DVB
broadcasters, or the entire feed from a particular cable or
satellite operator. I recommend at least giving an example,
perhaps using wording something like that in my original draft

(6) Concerning the eighth requirement: As I indicated in an
earlier email message, I think we should restrict ourselves to a
TV (or DTV) URI scheme which references resources in TV (or DTV)
broadcasts. There are already other URI schemes for referencing
resources in the Internet and in local storage. Referencing
resources in a home network or in future networks is likely to
turn into a can of worms, and there is no real reason why that
should be within the scope of a TV URI scheme.

To the extent there is concern with identifying a specific
resource within an MPEG-2 transport stream when the transport
stream has been recorded on a local storage system, I think the
appropriate URI would be something like file://x.y.z? uri>,
where file://x.y.z gets you to the file on the storage system
which contains the transport stream. This is much the same
approach you would have to take if you took a collection of files
from a web server, packaged them up into a ZIP file, and stored
the ZIP file in a storage system.

To the extent there is concern with runtime resolution of
references between components of an MPEG-2 transport stream which
has been stored on a local file system, the file system is no
longer relevant once the stream starts playing. What you now have
is a transport stream coming into a receiver. It looks like a
broadcast, although possibly with a considerable time shift, and
typically coming from a different physical channel than the one
it originally came from. This is somewhat comparable to taking
the entire file system from one web server and moving it to
another web server. Whether the cross links still work or not
depends on whether the authors consistently used relative URIs.
It turns out that the URI translation mechanism I proposed last
week probably does deal with this situation correctly, as long as
the entire transport stream has been recorded, but I don't think
this should be a requirement.

To the extent there is concern with a situation where there are
cross links between a live broadcast and a stored event, or
between two stored events, or between a web server and a stored
event, there is no magic. If one moves a bunch of files from one
web server to another, this will "break" references to these
files from other files on the web server which have not been
moved. The URI translation mechanism I proposed last week
probably does deal with this situation correctly when the stored
stream/s is/are played into a DTV receiver, but I don't think
this should be a requirement.

(7) We need to clarify the "interoperate" statement in the tenth
requirement. I gather the intent is that typically a receiver
should be able to interpret an http: URI as a tv: URI and
correctly access the resource if the resource is in fact
available in the broadcast streams coming to that receiver. If
that is the intent, we need to say so more clearly.

(8) There is a minor typo in the Acknowledgements section. The
word "heighly" should be "highly".

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