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

At 11:12 PM 12/21/98 -0800, Roy T. Fielding wrote:
>>I understand your concern and it is perfectly valid in HTTP/Internet
>>systems with on-demand servers/proxies, or when the resource is a document
>>object.
>>
>>However, referencing other data objects and streaming video/audio content
>>in a broadcast carousel introduces some unusual circumstances not really
>>contemplated in traditional HTTP-like document schemes.
>
>No, it doesn't.  Figure out what the resource is and then define a
>naming scheme for that resource.  If the resource is a time segment on
>a particular broadcast, then it should have an identifier that indicates
>the broadcast channel and time segment.  If, however, the resource is
>something less broadcast dependent, such as "Buffy the Vampire Slayer,
>episode 24", then it shouldn't have a channel and time segment.

We agree.

>Whatever you do, never mix these two paradigms -- there is no reason
>why a streaming video/audio content cannot have more than one URI,
>so it is always better to use multiple references rather than try to
>over-identify something within a single URI.

We agree again.

>There is no difference here between HTTP and broadcast, other than the
>fact that the 'http' URL contains a hostname.  The philosophical properties
>of naming are the same.

Here is where we may diverge somewhat.  Taking the example of a broadcast
HTML document, the problem is in fully specifying it's "location".  For
example, let's say this document will be part of a broadcast stream and it
is known in advance that it will be sent at 1:00am tonight on some stream,
and at no other time and no other stream.

Is it appropriate to put this broadcast time (and stream specifics) in the
URL?  Or, should the URL simply be an opaque pointer to the object, and
broadcast time (and stream specifics) be communicated to the recipient by
some other means?  The former would permit, with only the URL, to locate
and acquire the object (albeit somewhat delayed in delivery).  The latter
case would *require* that a document cache be maintained (which is useful
anyway for other purposes) and it would either get a cache hit or not at
any given point in time - no acquisition could occur with the URL alone,
and no feeback to the user could be provided saying that "I don't have it
now, but I will at 1:01am".

Thoughts on this?  I personally think both will prove useful, but the
problem suggests that URL's in broadcast systems might take on another
dimension to specify a "location" that is not relevant in non-broadcast
systems.

Are you aware of any previous work in the area of multicast proxies and
URL's?  How about generally locating objects in streaming (Internet push)
content that might apply?

Thanks,
	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 11:42:53 UTC