Re: Format of RTSP URLs

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> Thu, 17 July 1997 15:23 UTC

Received: from cnri by ietf.org id aa09699; 17 Jul 97 11:23 EDT
Received: from services.bunyip.com (services.Bunyip.Com [192.77.55.2]) by cnri.reston.va.us (8.8.5/8.7.3) with ESMTPid LAA11917; Thu, 17 Jul 1997 11:21:46 -0400 (EDT)
Received: (from daemon@localhost) by services.bunyip.com (8.8.5/8.8.5) id KAA29497 for uri-out; Thu, 17 Jul 1997 10:56:59 -0400 (EDT)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.8.5/8.8.5) with ESMTP id KAA29428 for <uri@services.bunyip.com>; Thu, 17 Jul 1997 10:56:51 -0400 (EDT)
Received: (from daemon@localhost) by mocha.bunyip.com (8.8.5/8.8.5) id KAA05819 for uri@services; Thu, 17 Jul 1997 10:56:51 -0400 (EDT)
Received: from paris.ics.uci.edu (paris.ics.uci.edu [128.195.1.50]) by mocha.bunyip.com (8.8.5/8.8.5) with SMTP id KAA05816 for <uri@bunyip.com>; Thu, 17 Jul 1997 10:56:47 -0400 (EDT)
Received: from kiwi.ics.uci.edu by paris.ics.uci.edu id aa23858; 17 Jul 97 7:56 PDT
To: Brad Hefta-Gaub <brad@prognet.com>
cc: "'bill@syd.dit.csiro.au'" <bill@syd.dit.csiro.au>, Rob Lanphier <robla@prognet.com>, "confctrl@isi.edu" <confctrl@isi.edu>, "uri@bunyip.com" <uri@bunyip.com>, "www-talk@w3.org" <www-talk@w3.org>
Subject: Re: Format of RTSP URLs
In-reply-to: Your message of "Thu, 17 Jul 1997 02:06:07 PDT." <01BC9256.063C7740@zappo-home.prognet.com>
Date: Thu, 17 Jul 1997 07:44:34 -0700
From: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Message-ID: <9707170756.aa23858@paris.ics.uci.edu>
Sender: owner-uri@bunyip.com
Precedence: bulk

>Let's for the moment ignore the issue of a file system add-on that you
>and Roy have dismissed as being handled by "redirection"... would 
>your arguments be the same if the container media stream was being 
>"generated" on the fly by a "cgi-bin" like add-on to the media server?

Yes.  The CGI interface includes two mechanisms for passing parameters
to the script within the URL.  The first is extra path information; the
second is the query string.  If you use the former, then relative paths
are possible.  If you use the latter, then relative paths are impossible.

>Imagine a cgi-bin that produces a video container file with a stream
>of randomized fractal images which morph along the timeline of the 
>presentation synchronized with a music audio stream. Imagine that 
>such a cgi-bin actually produces a resource which is a real AVI file, 
>such that if said cgi-bin was running on a web server today it would 
>work exactly as one might expect. The url for such a resource might
>be...
>
>  http://foo/cgi-bin/fractalavi.exe?c1=ff00ff&c2=444400&e=0.3
>
>Now, are you suggesting that a media server which knows the AVI file 
>format, and needs to demultiplex this AVI file and send each of its 
>contained streams to different ports, should inform the client of
>the existence of these streams, and should be informed of the port 
>selections by the client via the following urls?
>
>  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/audio
>  rtsp://foo/cgi-bin/fractalvid.exe?c1=ff00ff&c2=444400&e=0.3/video

Of course not, since as I said before the query part of the base URL
is STRIPPED OFF before any relative parsing.  Try your example with
any current web server and see for yourself what the browser does.

At the same time, there is absolutely nothing preventing the CGI script
from using the URL

   rtsp://foo/fractalvid/morph/c1=ff00ff+c2=444400+e=0.3/audio

to mean the exact same thing.  The only difference is in the configuration
of the server and how the CGI parses its own input.  The same applies to
Apache API modules, NSAPI, ISAPI, and most other means of connecting a
content handler to a web server.  The argument that a database somehow
needs a query part is not relevant to the URL specification.

....Roy