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

From: Michael A. Dolan (
Date: Mon, Dec 21 1998

Message-Id: <>
Date: Mon, 21 Dec 1998 10:23:00 -0800
To: Dan Connolly <>
From: "Michael A. Dolan" <>
Subject: Re: Don't put descriptive info in a URI, only identifying info

Hi Dan-

Long time no talk...

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

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.

I think the TV application deserves some further thought before out of hand
discarding it as not being compliant with general requirements that I
believe did not contemplate this unusual broadcast/multicast system

The requirements being listed here on this list are very likely to result
in multiple URL schemes, some of which will meet your test, and some of
which may not (for good reason, I believe).  For example, without time as a
specifier, how would one uniquely reference a broadcast program that starts
at 12:00pm, as opposed to one that starts before or after this time on the
otherwise same stream?  There is no discrete object - just a stream where
time is a critical identifier component.

The matter is admittedly cloudier when trying to capture a traditional
document object that is on a broadcast carousel.  However, the problem
remains that the object may only be broadcast from 1:00-1:01 am and at no
other times.  The capture time could (and perhaps should) be specified out
of band, but omitting it from the general requirements may not be the right
way to tackle the issue this early in the definition process.

It would be my recommentation that the (time) addressing requirement
remain.  In the resulting URL schemes, where they reference documents, then
the URL guidelines should definitely be followed wherever applicable, and
if timing information is required, then out of band definitions should be
strongly considered.

Completely eliminating the timing requirement will break the resulting
overall designs.


At 11:24 AM 12/21/98 -0600, Dan Connolly wrote:
>In a review of a draft of requirements for a TV URL scheme[1],
>I just noticed:
>|4.The URI scheme MUST support for OPTIONAL information
>|     from which it MUST be possible for a receiver to determine
>|     the time period(s) within which the resource can be retrieved
>|     from the (also resolved) location. 
>This conflicts with a design principle I hold about URIs,
>explained in my message to the uri list in Feb 1997[2]:
>|If you're talking about "the document XYZ, which has title
>|ABC" then then ABC must not be part of the identifier. Because
>|you might want a reference ala "the document XYZ, which
>|has author Fred" to be recognized as the same resource.
>|On the other hand, you might refer to a resource using
>|a restrictive clause: "the service ZZZ that started in 1996".
>|In this case, "the service ZZZ that started in 1995" is a
>|distinct resource. So the year is part of the URL.
>I started to (a) ask the editors of [1] to
>cite the URL scheme guidelines[3], and (b) remove requirement
>4 since it conflicts. But [3] doesn't say anything about
>[2], so first I'm asking for [3] to reflect [2].
>I think [2] provides enough text for the editors to work
>with, but if it doesn't, let me know and I'll try to
>provide some.
>[1] TV Broadcast URI Schemes Requirements 
>                       26th November 1998 
>     Warner ten Kate <>. 
>     Gomar Thomas <>. 
>     Craig Finseth <>. 
>[2] Re: Attributes should only be there if part of the name/address
>Dan Connolly (
>Thu, 20 Feb 1997 10:05:36 -0600 
>Title           : Guidelines for new URL Schemes
>Author(s)       : L. Masinter, H. Alvestrand, D. Zigmond, R. Petke
>Filename        : draft-ietf-urlreg-guide-04.txt
>Pages           : 6
>Date            : 16-Nov-98
>Dan Connolly
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