RE: about tv:

From: Michael A. Dolan (miked@tbt.com)
Date: Wed, Feb 17 1999


Message-Id: <3.0.5.32.19990217094603.00b6cb60@cts.com>
Date: Wed, 17 Feb 1999 09:46:03 -0800
To: "Larry Masinter" <masinter@parc.xerox.com>, "Warner ten Kate" <tenkate@natlab.research.philips.com>
From: "Michael A. Dolan" <miked@tbt.com>
Cc: <www-tv@w3.org>, "Roy Fielding" <fielding@ics.uci.edu>
Subject: RE: about tv:

Larry-

First let me say thanks for providing some guidance on process and
direction which we will pursue on tv:.

A few comments below more in line with the bigger problem...

	Mike

At 10:33 PM 2/16/99 PST, Larry Masinter wrote:
>> I am trying to (after the fact) work on coming up with an acceptable
>> definition of tv:.  It has limited function, but it has proven very useful
>> in practice.
>
>I misunderstood the question. I thought you were trying to
>design something that would actually work well, starting
>with the existing definition of 'tv:'.

I wasn't the one that posed the original question, and the question, as
posed, was in fact what you answered and was being discussed on this list.
But, since I am the one defending this URI, I (re)posed the question I
wanted to defend.  :-)

>It sounds like you
>just want to describe what you have. I think you can do
>that, and the best thing to do is to describe its limitations
>and shortcomings, rather than to make up some reason why
>it's really great as is.

>> If the tv: syntax is that hopelessly offensive to everyone, I will stop
>> trying to defend it.  But that doesn't make it go away.  It is in current
>> public practice, and its use will grow a lot over the next year - well
>> before any other transport-independent scheme I know of is
>> deployed publicly.
>
>It's not "offensive", it just doesn't work very well. It would
>be useful to define something else that would work better --
>e.g., be well-defined in the context of a system with more
>than one TV tuner, for example, or for documents that were
>saved from TV onto a PC's disk. But that's not what you have.

Multiple TV tuners is a hard problem, but definitely something we need to
deal with.

Discrete items such as files, including A/V AVI and MPEG files, are easier
to think about than broadcast streams.  The latter can be characterized
into the former by focusing on the announcements (programs/events) and
breaking the stream into time segments.  However, there is a need for a
(URI) reference that points to the (conceptually) infinite stream itself.
So, in this context, tv: has value.  No, it will never be used to reference
a discrete item on a disk anywhere.

The analogy on the Internet is trying to come up with a URI to point to an
MBONE broadcast that has the SDP attribute "t=0 0".

>...And I'm dubious about
>the assertion that other standards bodies can't possibly reference
>"informational" RFCs.

This is 2nd hand information on my part.  I will investigate further.
Specifically I am concerned about DVB and ATSC, and am currently getting
varying answers...

>> So, in summary of where I think we are is that we have
>> established that to put live TV in an HTML page, you need
>> a URI scheme(s) (or at least noone objected to Werner and
>> my premise statements to this).
>
>Oh! No, I think that's nonsense. Of course you don't
>need a separate URI scheme. I gave you several
>counter-proposals, for that matter; a URI that referenced
>the context of transmission that was independent of
>"tv:", a MIME type which was invoked either by a HTTP
>URL or even a "data:" URL, etc.

The private discussion to which you refer was in another context of
providing stream control information, and not reference to the video and
audio stream itself.  However, I see your point.  One could refer to a TV
stream in an HTML page as:

	<OBJECT TYPE=video/mpeg>

However, all the same problems still surface.  What stream?  What tuner?
These can be solved with HTML tag attributes, but the one that cannot be
solved in this form is making this reference be transport independent.  One
must necessarily specify the exact content type, which will, by definition,
not work across all transports.  I suppose one could invent a generic
content type (application/tv-stream), but then all the vagueness creeps
back in that we have with tv: (and probably someone would object to a
content type not really being defined).

Did you have a specific idea here that I am missing?

>> then the primary question is: can we specify tv: in
>> *some* manner that is well-defined within the requirements
>> of a URI.
>
>What if the answer is "no"?

Then we have another news: I guess.  But the sooner we can contain its
definition, the better.

	Mike

------------------------------------------------------
Michael A. Dolan, Representing DIRECTV,  (619)445-9070   
PO Box 1673 Alpine, CA 91903        FAX: (619)445-6122