Re: Format of RTSP URLs

"Roy T. Fielding" <> Tue, 15 July 1997 17:58 UTC

Received: from cnri by id aa14381; 15 Jul 97 13:58 EDT
Received: from (services.Bunyip.Com []) by (8.8.5/8.7.3) with ESMTPid NAA05120; Tue, 15 Jul 1997 13:57:15 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id NAA07628 for uri-out; Tue, 15 Jul 1997 13:41:53 -0400 (EDT)
Received: from (mocha.Bunyip.Com []) by (8.8.5/8.8.5) with ESMTP id NAA07623 for <>; Tue, 15 Jul 1997 13:41:45 -0400 (EDT)
Received: (from daemon@localhost) by (8.8.5/8.8.5) id NAA25167 for uri@services; Tue, 15 Jul 1997 13:41:44 -0400 (EDT)
Received: from ( []) by (8.8.5/8.8.5) with SMTP id NAA25164 for <>; Tue, 15 Jul 1997 13:41:41 -0400 (EDT)
Received: from by id aa01032; 15 Jul 97 10:40 PDT
To: Rob Lanphier <>
Subject: Re: Format of RTSP URLs
In-reply-to: Your message of "Mon, 14 Jul 1997 20:07:26 PDT." <>
Date: Tue, 15 Jul 1997 10:28:52 -0700
From: "Roy T. Fielding" <>
Message-ID: <>
Precedence: bulk

>Without getting into too much depth about the protocol itself, we are
>trying to sort out how the protocol should handle multi-stream container
>files (ala Quicktime, ASF, RealMedia File Format, which often contain both
>audio and video streams, and may contain many other types).  It is the
>consensus that it is important for the protocol to deal in a distinct
>manner with the different streams.  The controversy stems from if/how the
>URL is used to achieve this.
>A promenent proposal for achieving this is as follows:
>Full Container file:
>Individual Track within container file:
>(the "track=1" portion is file format specific, the "?" is the consistant
>The issues we are debating are:
>1.  Whether the protocol should make special accomodations for multistream
>container files
>2.  If yes, if/how should that be expressed in the URL

If we were talking about URLs in general, then you could do whatever
you want within the constraints of the urlc character set.  Even with
hierarchical URLs, there is complete freedom as to the syntax within
the path and query.  HTTP does distinguish between the path (which
defines the resource) and query, but that is due more to particularities
of the implementations rather than any hard requirement of the protocol.

The URL spec only defines those parts of the hierarchical syntax that
effect the parsing of relative URL references, since that parsing must
be scheme-independent.  Outside those requirements, the spec allows a URL
scheme to define its own reserved syntax as it wishes.  However, it is
assumed that if hierarchy is important, then "/" will be used to separate
hierarchical segments.

If the server is always providing the URL, then the URL syntax of
subparts of a particular resource can be left to the server.  In other
words, unless the client is allowed to "munge" the URL in order to
directly access a subtrack of that URL's resource, then the server
should decide what syntax to use.  Naturally, I would prefer


since a track is itself a resource.

If the client is expected to do URL munging, then you will have to
standardize a syntax for rtsp.  Again, for rtsp, you could choose
anything as the standard.  However, if your *real* concern is that
the syntax be usable by existing platforms with a CGI-like interface,
then there are only two reasonable alternatives:

    rtsp://       (extra path)
    rtsp://       (query parameter)

Using ";" was an idea of mine that can be seen in RFC 1808, but
was never supported by HTTP servers.

>I'm going to switch here to representing myself and Progressive Networks.
>Here's the concern that we have.  "?" is used in HTTP as the query
>delimiter, and the "?track=1" use isn't consistant with that.

It is only inconsistent if you want to treat the track as a resource,
and not as just a retrieval operation on a larger resource.  Using
extra path information does not suffer from this limitation, but
only works when the extra segments are hierarchical in nature.
Containers are hierarchical in nature.

>*  We want the authoring scenarios to be protocol independent.  If someone
>goes through the trouble of writing the media metafile and web page which has
>different streams from the same container showing up on different parts of
>the page, we want that metafile to be the same whether or not the content
>is actaully being streamed via RTSP or HTTP.

I assume that you mean RTSP would respond with the container's streams
and HTTP would respond with the metafile, which the client would read
and make separate requests for the individual streams.

>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.
>This server-side fragment id would allow the client to play around with the
>URL without messing up the query portion.  ":" is presented only as a
>strawman.  I'm not sure what the correct character would be here.

Traditionally, the only thing the client can "play around with" is
the query part.  It would be syntactically ambiguous to append another
component to the query.  The ";param=value" syntax of RFC 1808 was only
possible because the URI spec had traditionally defined ";" as being
reserved in the path.  However, that was found not to be true in practice.

>The point here is to make it as simple as possible for a server to add and
>subtract fragments from the server-side fragment portion.  If this is
>buried in the query, it's very difficult.  If it is clearly delimited and
>hanging off of the end, it's really straightforward.

That is a severely weak argument.  On a server like Apache or NCSA,
it is actually easier to process that information if it is part of
an extra path and not tagged onto query.  The best syntax for an
existing server will be highly dependent on how the server manages
its namespace, which means the best syntax is one that fits within
the logical structure of a namespace.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715