RE: Don't put descriptive info in a URI, only identifying info

At 03:45 PM 12/22/98 PST, Larry Masinter wrote:
>Think of the 'news' URL scheme, and our (unsuccessful) attempt to
>separate out 'news' and 'nntp'...
>
>...So it's not as if we have no experience with other kinds of
>'streaming broadcast' material in the URL space.

I personally value greatly your, Roy and Dan's thoughts in this space.  I
trust everyone else does as well.  I only hope that this list keeps your
attention, as we will all benefit from your input.

But, I'm not sure too many of the TV scenarios map into news: all that
well.  In the case where there is a stream of discrete objects with tagged
ID's not found anywhere else, it is at least a better analogy.  One
difference though is that news has no concept of broadcast time - the
messages arrive synchronously on request from a recipient.  One can
"locate" a news item by querying the news server on demand.  The news
servers themselves are synchronous distribution systems - not exactly
broadcast in any part of it, including the recipient using the URL.

Broadcast systems (TV) are highly driven in the temporal space.  One cannot
request an object without puting a caching gateway in-between the recipient
and the broadcast.

>In the netnews space, at least, articles have unique IDs that
>allow them to be identified independently of the stream in 
>which they are broadcast. That isn't the case for most of TV
>today (is it?)

In no existing transport today are programs identifiable in a globally
unique manner.  When they are tagged at all, they are done so in a
transport-specific way.  Ditto for even just channels.  So, the tv: URL
problem is plagued first and foremost by a lack of a good namespace(s) to
work with.  Hence, solving the namespace problem is high on the design list.

Some people have proposed tagging everything of interest with opaque (URI)
identifiers.  Others propose schemes that are transport specific (DAVIC/DVB
for example).  Neither is a great solution (at least in my opinion).

>so you may need more designators, but don't try
>to pack an arbitrarily complex expression into the locator.
>The scenarios will help figure out what's truely useful.

Roger.

	Mike

---------------------------------------------------------------------------
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 Tuesday, 22 December 1998 19:56:00 UTC