Re: Format of RTSP URLs

[Rob Lanphier <[e-mail]>]

At 01:44 PM 7/15/97 +1000, Bill Simpson-Young wrote:
>robla wrote:
>> ...
>> The URL scheme, taken from Roy Fielding's draft on the subject
>> (draft-fielding-url-syntax-05.txt) is something we'll have to consider very
>> seriously in all of this.  The URL syntax there is:
>> <scheme>://<site>/<path>?<query>#<fragmentid>
>> 
>> The problem with that scheme is that "fragmentid" is really "client-side
>> fragment id".  What we really need is a server side fragment id as well.
>> 
>> <scheme>://<site>/<path>?<query>:<ssfrag>#<fragmentid>
>
>In RFC 1808, the URL syntax is 
>
><scheme>://<net_loc>/<path>;<params>?<query>#<fragment>
>
>where "params   ::= object parameters (e.g., ";type=a" as in
>                       Section 3.2.2 of RFC 1738 [2])."
>
>Why not use params which is intended for this purpose?  I know the 
>"params" isn't used in the HTTP scheme but the disadvantages of using ? 
>and # are great enough that it's better to use params than stay close to 
>the HTTP scheme.

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 "#").

One way to route around this is to always use absolute URLs, but I think
that would be slightly more prone to error.


---
Rob Lanphier               Voice: [phone]         Fax: [phone]
Program Manager-Protocols                         Email: [e-mail]
Progressive Networks-Home of RealAudio            Web: http://www.real.com
For more information on firewalls:       http://www.real.com/firewall.html
For more information on RTSP:               http://www.real.com/prognet/rt