Re: TV Broadcast URI Schemes Requirements

From: Jeff Sussna (
Date: Wed, Nov 24 1999

Message-ID: <>
From: Jeff Sussna <>
To: "''" <>
Date: Wed, 24 Nov 1999 14:49:47 -0800
Subject: Re: TV Broadcast URI Schemes Requirements

I have some comments on the TV Broadcast URI Schemes Requirements document:

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.

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?

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?

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.

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

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. 


Jeffrey E. Sussna
Chief Architect
Quokka Sports, Inc.
Digital Sports Entertainment

128 Spear St. Suite 200
San Francisco, CA USA 94105
+1 415 369 4286