Re: TV Broadcast URI Schemes Requirements

From: Craig A. Finseth (
Date: Mon, Nov 29 1999

Date: Mon, 29 Nov 1999 09:08:59 -0600 (CST)
Message-Id: <>
From: "Craig A. Finseth" <>
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.

   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.

   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.

   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

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.