Subject: Re: [MMUSIC] RTSP: Speed header

From: "Joseph Pallas" <[email-masked]>
Date: Tue, 24 Apr 2007 11:37:54 -0700

It sounds like there is some consensus here.  I want to chime in
because Ross's comment aligns well with recent remarks by Magnus.
RTSP 1.0 has not been as useful a standard as we would like.  It
includes some things that no one uses, it omits some things that many
users want, and in a few areas it actually prohibits desirable
practices (unintentionally).  The result has been poor
interoperability.

I wasn't active in this community at the time RTSP 1.0 was being
drafted, but it seems to contain features that were deemed "nice to
have" without any implementation experience.  I think Ross is
suggesting that's part of the problem, and I agree.  Anything we can
do to minimize this problem for RTSP 2.0 will make it a better
document.

joe

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Jean-Francois Mule" <[email-masked]>
Date: Thu, 26 Apr 2007 16:53:26 -0600

> practices (unintentionally).  The result has been poor

Some of this was discussed back then when the 2.0 draft was started. It
would be nice to get some specific details based on the current 2.0
drafts, especially the "things [in the current 2.0 draft] that no one
uses", and what results in "poor [1.0] interoperability".

Jean-Francois.

---

From: "Joseph Pallas" <[email-masked]>
Date: Fri, 27 Apr 2007 13:46:28 -0700

> uses", and what results in "poor [1.0] interoperability".

I think the 2.0 draft is much better than 1.0 in these respects; I
won't bother to enumerate problems with 1.0.  For 2.0, we've already
identified the Speed header as one issue.  I think the lingering
references to connection-less transports are unnecessary, although
probably harmless.  There is no means to negotiate a content type for
GET_PARAMETER and SET_PARAMETER, so their interoperability remain
dubious.  (And I've already complained that there is no specification
for "text/parameters" despite its usage both in the field and in the
examples.)

I do not know whether any implementations are using the cache-related
features.  I'd be interested to hear what use is being made of them.
I think it would be quite challenging to implement a caching proxy
that supports independently-developed clients.

Having stated my concern about unused features, I would add this.  I
think it is telling that the ANNOUNCE method from RTSP 1.0 may have
never been used as specified (for unsolicited session descriptions)
but was "repurposed" by some implementations to provide a way to
signal various asynchronous stream events.  I agree with the decision
to remove RTSP 1.0's ANNOUNCE from RTSP 2.0, but I'm concerned that
failing to include that notification functionality in RTSP 2.0 simply
means that incompatible extensions will be created. (I would be
especially sad to see ANNOUNCE-as-it-is-used re-introduced as an RTSP
2.0 extension.)

joe