Re: Format of RTSP URLs

Rob Lanphier <> Tue, 15 July 1997 19:12 UTC

Received: from cnri by id aa16302; 15 Jul 97 15:12 EDT
Received: from (services.Bunyip.Com []) by (8.8.5/8.7.3) with ESMTPid PAA05396; Tue, 15 Jul 1997 15:10:52 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id OAA09282 for uri-out; Tue, 15 Jul 1997 14:55:01 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id OAA09273 for <>; Tue, 15 Jul 1997 14:54:57 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id OAA25535 for uri@services; Tue, 15 Jul 1997 14:54:56 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id OAA25530 for <>; Tue, 15 Jul 1997 14:54:52 -0400 (EDT)
Received: from ( by with SMTP id AA27475 (5.67b/IDA-1.5 for <>); Tue, 15 Jul 1997 11:59:28 -0700
Message-Id: <>
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Tue, 15 Jul 1997 11:52:44 -0700
To: "Roy T. Fielding" <>
From: Rob Lanphier <>
Subject: Re: Format of RTSP URLs
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Precedence: bulk

At 11:03 AM 7/15/97 -0700, Roy T. Fielding wrote:
>robla wrote:
>>I think this may be acceptable, but there's one other possible requirement
>>I'd like to mention.  It would be nice to have the ability to have relative
>>URLs, so that, for example, the following scenario can play out (using ":"
>>as a server side fragment identifier for the time being)
>>C->S  DESCRIBE rtsp://foo/db/moviebase?movie=twister RTSP/1.0 1
>>S->C  RTSP/1.0 200 1 OK
>>      Content-length: 178
>>      Content-type: application/sdp
>>      s= sample rtsp presentation
>>      r = rtsp://foo/db/moviebase?movie=twister   /* aggregate URL*/
>>      m= audio 0 RTP/AVP 0
>>      r = :track=audio1                           /* URL to control audio*/
>>      m=video 0 RTP?AVP 26
>>      r = :track=video1                           /* URL to control video*/
>>At this point, the client can easily discern that the audio track and the
>>video track are indeed merely fragments of the same object on the server,
>>and not separately controlled entities.  I'm not sure how this would work
>>with ";" parameters, since the relative behavior defined in 1808 is
>>different than what I'd expect above (which is more akin to "#").
>Those relative URLs would resolve to
>      rtsp://foo/db/:track=audio1
>      rtsp://foo/db/:track=video1
>which is obviously not what you would want.  

I'm not aware that there is currently a spec for server-side fragments (and
colons beyond the port position of an URL), which is what I'm suggesting is
a necessary feature for relative URLs to work.  I would expect that the
rules that apply to client-side fragments ("#whatever") would also apply to
server-side fragments.

I'd suggest they resolve to the following:

...just as if you were to replace ":" with "#".  The colon may be a bit
overloaded here, and may be too easily confused with semicolon, so perhaps
a better separator is in order.  However, I'm at a loss to come up with
such a beast.

>Query info and relative
>references do not mix in practice.

I don't think it is much of a stretch to say:

...which returns some html with:

<a href="#top"> it.  Isn't this done all of the time?

> In any case, using query info to
>select a resource, as opposed to redirecting to the real resource URL,
>is poor namespace management.

It may be the case that the real resource is stored in a database that must
be accessed via query.  

Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email:
Progressive Networks-Home of RealAudio            Web:
For more information on firewalls:
For more information on RTSP: