Subject: Format of RTSP URLs

From: Rob Lanphier <[email-masked]>
Date: Mon, 14 Jul 1997 20:07:26 -0700

Members of www-talk and uri,

First, an introduction:  the confctrl group is currently working on the
Real Time Streaming Protocol (RTSP), which is for control of on-demand data
with real-time properties (usually multimedia).  See
http://www.real.com/prognet/rt for more details on this.

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:
rtsp://foo.com/example.mov

Individual Track within container file:
rtsp://foo.com/example.mov?track=1
(the "track=1" portion is file format specific, the "?" is the consistant
part).

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

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.  We want to
make sure that things are as consistant as possible between RTSP and HTTP
because:

*  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.
*  One day, given the similar appearence of RTSP and HTTP, there may be an
effort to merge RTSP and HTTP, or to define some common framework that both
share.  We want to avoid pain when we can.
*  Frankly, we want to make sure that someone could implement a "cgi"
filesystem using the RealMedia Architecture that works as similarly as
possible to HTTP.  Any binding of "?" to protocol operation makes this
difficult/impossible.

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>

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.

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.

I don't want to drag anyone here into a debate about whether or not
container file accomodations are needed (though I would welcome those who
want to dive in further and comment on confctrl), but I'm mainly interested
in is what the feeling is with regards to new URL schemes and consistancy
with HTTP.

Background information on this issue can be found in the following mail
archive:
http://www.mbone.com/lists/confctrl.1997/

Of particular interest will be:
"Container files and various methods of dealing with them" thread (the
inaugural message)
"Solving 1-1-n" thread
"Format of RTSP URLs" thread
"Sessions, presentations and URLs in RTSP" message

Many thanks in advance for your insight on this.

Rob

---
Rob Lanphier               Voice: (206)674-2322         Fax: (206)674-2699
Program Manager-Protocols                         Email: [email-masked]
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

---

From: Bill Simpson-Young <[email-masked]>
Date: Tue, 15 Jul 1997 13:44:24 +1000

Rob,

> rtsp://foo.com/example.mov

Ideally, people won't do this but would do rtsp://foo.com/example and 
leave the type up to content negotiation.

> (the "track=1" portion is file format specific, the "?" is the consistant

If format-specific info is to be included in a specific RTSP URL, then it 
makes sense to allow an HTTP-style query part for the specification of 
this but the internal syntax of that part should be outside the scope of 
the scheme.  However, I think there is a need for the standardisation of 
some RTSP scheme- dependent semantics for commonly-used properties so that 
it is rarely necessary to resort to format-dependent references.  Eg in 
this case, one should probably use something like "track=audio1" (but this 
wouldn't be in the query part of the URL - see below).

> ...

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.

> hanging off of the end, it's really straightforward.

I agree.

Bill

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 15 Jul 1997 10:28:52 -0700

>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

    rtsp://foo.com/example.mov/track-1

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://foo.com/example.mov/track-1       (extra path)
    rtsp://foo.com/example.mov?track=1       (query parameter)

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

>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.

>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.

>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.

>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    ([email-masked])
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-1715
    http://www.ics.uci.edu/~fielding/