RE: TV Broadcast URI Schemes Requirements

-----Original Message-----
From: Craig A. Finseth [mailto:fin@finseth.com]
Sent: Monday, November 29, 1999 7:09 AM
To: jeff.sussna@quokka.com
Cc: www-tv@w3.org
Subject: Re: TV Broadcast URI Schemes Requirements


   1. The document states that a URN may contain hierarchical structure,
   similar to that of a URL. Interestingly, the URN spec (RFC 2141) reserves
   the slash character but does not impute any semantics to it. I believe
that
   the slash character should have the same semantics as in URL's, i.e., to
   denote hierarchy (logical in the URN case, physical in the URL case). I
   would certainly support anyone's efforts to get the IETF to formally
adopt
   these semantics for URN's.

Actually, the hierarchy is logical in both cases.  However, in 99% of
the cases, logical===physical for URLs, so this is a minor distinction.

RESPONSE: You're right.

   2. It occurs to me that we may be dealing with two different beasts here.
   Beast A is "the event that happens at 9:00 on Sunday night on the FOX
   service". Beast B is "Episode 432 of the X-Files". In the case of my
example
   they refer to the same underlying content. It seems that beast A implies
a
   URL and beast B implies a URN. Are they really, however, the same thing?
   Does it make sense to mix them? Or is it necessary to connect them via
   metadata? In other words, would you ever refer to "Channel 2/X-Files", or
   only to either "Channel 2/Sunday/9:00PM" or "Fox/Drama/X-Files"? Metadata
   could tell you that "Channel 2/Sunday/9:00PM" was a presentation of
   "Fox/Drama/X-Files" (and vice versa). What I'm wondering is whether the
   schedule and content aspects of TV URI's need to be radically separated
from
   each other from a resource identification point of view?

So far as I know, there is no one in the country who cares about
watching Channel 2/Sunday/9:00pm.  However, lots of people want to
watch the X-Files.  What people want identified is the content, not
the time slot.

We are used to thinking about the time slot being synonymous with the
material, but with EPGs, the box can handle the mapping.  This
indirection also allows the box to adjust to changes in the schedule.

Note also that "Channel 2/Sunday/9:00PM" is not a URL as it is not
universal: my Channel 2 is undoubtedly different from your channel 2.
And, while this can be fixed, the fixes move the whole system in the
URI direction...

In the few cases where one needs to identify a particular showing, the
proposed scheme can deal with it in the obvious fashion.

RESPONSE: Totally agreed. All I was trying to do was make the point that the
indirection (i.e., the separation of the two), is necessary.

   3. The document states that "given a URI, it must be possible for a
receiver
   to actually locate the resource, or conclude that it is not reachable?"
   Doesn't this rely on the presence of extrenal software? I.e., URN
resolvers
   and the like?

No, it relies on mapping tables.  All resolution is handled in the
receiver.  The assumptions section clearly indicates that any scheme
must operate in a "receive only" mode.

RESPONSE: In my mind, a mapping table IS a URN resolver. Anyway, it still
seems beyond the scope of the URI spec.

   4. Ditto for the requirement that a URN be resolvable under all network
   access conditions? Perhaps what's really being stated here are
requirements
   for software environments that use TV URI's.

You are correct in pointing out that there is some mixing here, but the
requirements do affect the solution space.

   5. I'm not sure I agree with the requirement that a URN reference
"various
   instantiations of the same content". Is it really the same content?
Maybe.

This question can only be answered by the content creator.  The requirement
is that, in those cases were multiple instantiations _do_ reference the
same content, the URN scheme support this case.

   How do the mechanics work? If I hand a URN to a URN resolver, do I expect
it
   to give me back multiple URL's, and then I choose the one I want (i.e.,
at a

You hand a URN to a resolver, which returns a (possibly empty) list of
matching resources.  You then query each resource to determine its
characteristics.

Keep in mind that the URNs are assigned by the content creator, so you (as
the content creator) will have a pretty good idea of what resources will
be returned and how they should be used.

   bitrate I can handle)? How do I tell which is which? Is it encoded in the
   URL? Do I go get some RDF metadata for it? Seems that if the protocol is
   going to require this, the protocol should define it as part of the
resource
   identifier. Otherwise the negotiation process is left up to software
   implementations and is therefore not standardized. 

The scheme is intended to be transport-independent.  It can thus not specify
any particular mapping scheme.

We assume that each transport scheme will adopt its own mapping
scheme.  One has been proposed for ATSC (and, with the obvious changes
due to the differences in PSIP structures, could be used by DVB).

   6. To restate my above comment more generally, I would add to the
   requirements that a TV URI must completely describe the content being
   identified. In other words, a TV resource identifier must in fact
uniquely
   (either by location in the case of URL or equality in the case of URN)
   identify a TV resource. 

It does this.

What it does not do (by design) is tell you from inspection how to
obtain the content (it is impossible to do this while remaining
transport independent): it relies on transport-dependent mapping tables
for this portion of the system.

RESPONSE: Yes, it does this, except in the case where a URI returns multiple
resources. This seems to me to go against at least the spirit of URI's. It
also makes me uncomfortable to think about a scheme where I don't know
exactly what I'll get except in some content-provider specific way. Note
that Apache had the notion of content negotiation which never quite made it
to universality, and thus never was fully usable.

Jeff

Received on Monday, 29 November 1999 13:51:46 UTC