Subject: Suggest making streamid an argument

From: v guruprasad (prasad) <[email-masked]>
Date: Wed, 22 Oct 1997 10:33:32 -0400 (EDT)

Folks,

Admittedly, it's late in the day for this, but I had not noticed the
streamid usage until the Interop.

Instead of tagging the streamid as part of the "filename", as below

>     C->S  SETUP rtsp://foo.com/test.wav/streamid=0 RTSP/1.0
>           Transport: rtp/avp/udp;client_port=6970-6971;mode=play
>           CSeq: 3

I propose that it be tagged like an HTTP Form argument:

      C->S  SETUP rtsp://foo.com/test.wav?streamid=0 RTSP/1.0
            Transport: rtp/avp/udp;client_port=6970-6971;mode=play
            CSeq: 3

Pros:
-----

1. It eases parsing, enhances readability and promotes scalability.

The media content would be often stored, or addressed, in a directory
hierarchy.  Directory organization is often overlooked in the prototype
stage when there are relatively few sample contents, but becomes
important for services with more content, say with hundreds of movies, etc.

2. This would make the syntax more compatible with HTTP, in which the
slashes are interpreted as a (virtual) directory path and argument values
("=xxx") are demarkated with a question mark ('?').

It would also allow CGI-like implementation of the RTSP methods and the
reuse of "cgiparse" for grabbing the streamid or similar parameters.
Although this apparently buys little for Java-based (single-language)
implementations, we should allow the flexibility for efficiency of high
end servers that might be implemented in more traditional ways.

3. The change to the current prototype implementations is minimal.  In
C/C++, it would entail replacing an "strrchr (url, '/')" call with
"strchr (url, '?')".

4. I would expect the IETF to come up with these questions at some point
before granting approval as a standard.

Cons:
-----

1. It *could* be used by mutually agreeable clients and servers to shorten
a number of other parameters by passing them as URL arguments, thus
"collapsing" the protocol.  As an extreme example, consider:

      C->S  SETUP rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-6971&mode=play RTSP/1.0
            CSeq: 3

This would make sense because the arguments are specific to the stream
being setup, viz. 0, and any parameters that might have been overlooked
could also be tagged this way.  Such run-away extensions would not really
impact the standard, however, so the possibility should not be a problem.

---

From: Rob Lanphier <[email-masked]>
Date: Wed, 22 Oct 1997 11:03:51 -0700

I'll be nice because Prasad's a nice guy and I know he was a relative
latecomer to this mailing list :)

We spent a lot of time discussing the syntax of the URL in the July/August
timeframe, and I'd really like to encourage you, Prasad (and everyone else
who wasn't around for this discussion) to look at the confctrl archive at:

http://www.mbone.com/lists/confctrl.1997Q3/

There was a lot of mail on this subject, which is a lot to sift through,
but I think it's a necessary exercise to avoid derailing things.

Rob

At 10:33 AM 10/22/97 -0400, prasad wrote:
>      C->S  SETUP
rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-69
71&mode=play RTSP/1.0
>impact the standard, however, so the possibility should not be a problem.
---
Rob Lanphier ([email-masked])    Voice: (206)674-2322   Fax: (206)674-2699
RealNetworks:  http://www.real.com
RTSP Info:     http://www.real.com/rtsp
Firewall Info: http://www.real.com/help/firewall

---

From: Stephen Casner <[email-masked]>
Date: Wed, 22 Oct 1997 12:23:16 -0700 ()

>             Transport: rtp/avp/udp;client_port=6970-6971;mode=play

The short answer is you can do whatever you want with your server.
Since the server puts the URLs into the session description and the
client just blindly sends them back, they can be in whatever form you
like.

>       C->S  SETUP rtsp://foo.com/test.wav?streamid=0&transport=rtp/avp/udp&client_port=6970-6971&mode=play RTSP/1.0

This is not a good idea because those headers are to be interpreted by
proxies for whom the URL will also be opaque.
							-- Steve