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 15:37:20 -0800
To: "Larry Masinter" <>, "Warner ten Kate" <>
From: "Michael A. Dolan" <>
Cc: <>
Subject: RE: Don't put descriptive info in a URI, only identifying info


For the record, there are some folks that subscribe to the "grand unified
TV URL theory" [my words, not theirs].  But, there are others, myself
included, that do not, and feel that for the reasons you stated and others,
there will necessarily be multiple schemes in the end.

To the extent that the requirements document implies the former solution in
your reading of it is unfortunate in my opinion.

I am hoping that the recent aggregation of "application scenarios" on this
list will drive a revised requirements document, more openly permitting the
possibility of multiple schemes in the solution(s).


At 02:28 PM 12/21/98 PST, Larry Masinter wrote:
>Re ""
>(Minor note: RFC 2119 isn't really appropriate for use
>in a requirements document; the MUST/MAY/SHOULD levels
>apply to implementation compliance with a protocol
>specification, not specification compliance with
>protocol goals.)
>You identify a TV broadcast content model 
>(service, event, component, and fragment) but haven't
>justified the need for a URL scheme to span them all.
>TV channels and TV programs are different kinds of resources,
>and might need entirely different schemes, since they have
>very different kinds of access methods and specifications.
>The TVWeb-URI-Requirements seem to be written presuming that
>there's only one URL scheme.
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