RE: about tv:

> 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:'. 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.

> So, I think it is, in fact, a valuable exercise to try to define it in
> terms that might be acceptable to everyone in *some* context.  My
> assumption is that this list is the right forum for that discussion (even
> though I was *not* the person who initiated this thread).

It would be acceptable if you included in the description of "tv:"
all of the ways that it fails to behave as well as most other
kinds of URLs. There are other URL schemes that have problems,
too, so... that's OK. Just don't write it up in a way that would
encourage other URL designers to copy it. "news:" has problems,
for example, in that its meaning depends a lot on the context
from which it is invoked, and the configuration of the user
that invoked it. (That's one of the reasons why "news:" isn't
used much.)

> FYI, I took a definitional tact (URN) that was not in fact the original
> author's intent for tv: in the hopes that there was *some* definition that
> was clear and acceptable to everyone.

I don't think the URN tack is helpful.

>  Else it is relegated to an "informational" (RFC).

Probably that is the _best_ way to publish the definition, though.

>  But such an outcome is not in the best interest of
> the users of tv: as it will remain open to endless debate and some
> interpretation (especially if its context is ill-defined).  And,
> not having it standardized makes referencing the tv: URI
> problematic for certain other standards bodies.

I personally think that the best interest of the users of "tv:"
would be to define a different kind of referencing mechanism
that didn't have so many operational problems. Since you don't
want to do that -- you want to leave "tv:" as meaning what the
current users of "tv:" use it for -- then you're stuck with
second best. Publishing a definition of "tv:" as an Informational
RFC doesn't leave it open to endless debate or interpretation --
unless the document is poorly written. And I'm dubious about
the assertion that other standards bodies can't possibly reference
"informational" RFCs.

You might even be able to get away with standards-track in
IETF; I don't know. At a minimum, I think you'd have to do
a better job of dealing with the technical ambiguities of
the meaning of "tv:" outside of the context of a particular
mode of transmission, and that seems difficult to me.

> I would *love* to continue the bigger TV object naming
> discussion, and have given the subject a *lot* of thought.
> But I would (independently) like to close on defining tv:
> for the reasons stated above.

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

> If you believe that tv: is useful,

Sure, it's useful

> and will continue to be used no matter what,

No, certainly not "no matter what". If you defined something
better, and convinced current content authors and implementors
that it was better, you could migrate away from "tv:" to
a newer method.

> and that it should be well-defined as soon as possible
> by experts,

If it _can_ be well-defined while retaining backward
compatibility. Your arguments about continuing to use
"tv:" have to do with the current installed base. So
you can't actually change it in ways that are incompatible
with the installed base and retain any advantage.

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

> I solicit your expert help on this specific task.
>
> 	Mike
>
> At 09:54 AM 2/14/99 PST, Larry Masinter wrote:
> >The questions of "what is a URN" or "what is a URL" tend to
> >lean away from engineering and toward philosophy or even
> >religion.
> >
> >I suggest a different approach. Imagine, for a moment, the
> >possibility that an author might want to create content
> >which is intended to be delivered MORE THAN ONE WAY. That
> >is, not JUST by 'tv', but, say, the same content delivered
> >EITHER by 'tv' OR via HTTP on a (forfend) regular old PC.
> >
> >But what would a regular old PC do with this "tv" URL?
> >Clearly it doesn't mean "turn on the TV now and watch it".
> >There's some other semantics that is actually wanted;
> >you're invoking some image which is inherited from the
> >context, I suppose. I'm not entirely sure.
> >
> >I urge you to think out of the box and come up with
> >a design that's actually useful in multiple contexts.
> >Sometimes you get boxed in by imagining a world in which
> >everyone is just watching interacting with web pages
> >while watching their TV.
> >
> >But people don't just watch the web. They save it, store it,
> >forward it, mail it, put it in databases, search it.
> >How could you design something that would work in all
> >those other scenarios, at least as well as today's
> >'best practice' URL uses? Don't create a design that's
> >_only_ useful for "www-tv".
> >
> >Larry
> ------------------------------------------------------------------
> Michael A. Dolan, Representing DIRECTV,  (619)445-9070   FAX:
> (619)445-6122
> PO Box 1673 Alpine, CA 91903, Overnight: 20239 Japatul Rd,
> Alpine, CA 91901
>
>
>

Received on Wednesday, 17 February 1999 01:33:41 UTC