Subject: RE: RTSP: Text v. Binary Control

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Nov 1996 20:32:51 -0800

There is a certain logic to using a text-based approach, and converging the syntax
of the resulting headers with HTTP. In fact, when you consider the headers that are
likely to result from this, it becomes apparent that they would make useful additions
to the HTTP specification. 

Which begs the question: why can't the RTSP control functionality be implemented as
an HTTP extension?

---

From: Rob McCool <[email-masked]>
Date: Mon, 25 Nov 1996 14:56:41 -0800

> There is a certain logic to using a text-based approach, and
> converging the syntax of the resulting headers with HTTP. In fact,
> when you consider the headers that are likely to result from this, it
> becomes apparent that they would make useful additions
> Which begs the question: why can't the RTSP control functionality be
> implemented as an HTTP extension?

It could be implemented that way, there are a lot of benefits to doing
that. I think the question is how far toward HTTP RTSP should go. If
we're just talking about borrowing a slightly massaged version of the
HTTP syntax, then that's different than if we're talking about full
integration and interoperability with HTTP.

If we're talking about full integration, where RTSP is just an extension
of HTTP, then one difference is that HTTP requests are stateless. It
doesn't matter which order you send GET requests in, or whether or not
they all come on the same connection. Requests are not interrelated, and
connections can be dropped at any time. If each RTSP command was
implemented as a new HTTP method, then requests would become
interrelated and state would need to be kept by the server. If the
connection was dropped, would this imply a loss of the collected state
as it does in the current RTSP?

Also, if RTSP is an HTTP extension then it may make RTSP compliance more
difficult. It depends on how much of HTTP would be required for an RTSP
server/client to understand. Would an RTSP client and server be required
to implement all HTTP/1.1 "must" items?

With the wealth of HTTP resources out there this may not be a big deal
but it is something to keep in mind.

--Rob