Subject: Re: [MMUSIC] RTSP: Speed header

From: Magnus Westerlund <[email-masked]>
Date: Mon, 07 May 2007 16:24:24 +0200

Joseph Pallas skrev:
> On 4/26/07, Jean-Francois Mule <[email-masked]> wrote:
>> 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".
> 
> 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.

We are discussing on how to clean up the 2.0 spec, and I think that one 
thing that will consider is how to write the transport parts. I know of 
only a single UDP based RTSP transport which has had very limited 
deployment as it was a top-set box of some kind. In my opinion we can 
completely remove the consideration of running RTSP 2.0 over 
non-reliable transport.

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

Yes, I agree with that this isn't complete. Are you willing to write an 
definition of text/parameters?

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

I would also like to hear confirmation on that they implement this. I 
know Real has some proxy and it would be interesting to hear more about 
if it handles the caching features. But, these are cleaned up and I 
don't think it is that complicated to build a caching proxy. But there 
are a lot of streams out there that can't be cached because they are 
dynamically created for different users.

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

Do I understand you correctly that you rather see the asynchronous event 
signalling, like end of stream, to be in the base spec rather than as a 
extension specification. There was
http://tools.ietf.org/id/draft-ietf-mmusic-rtsp-announce-01.txt

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Torshamsgatan 23           | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

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

---

From: "Joseph Pallas" <[email-masked]>
Date: Tue, 8 May 2007 15:47:31 -0700

> definition of text/parameters?

Yuck.  I don't even like it.  But here's a stab:

A resource of type "text/parameters" consists of either
1) a list of parameters (for a query) or
2) a list of parameters and associated values (for an update).
Each entry of the list is a single line of text.  Parameters are
separated from values by a colon.

The ABNF [RFC2234] grammar for "text/parameters" content is:

(Note: this uses the "Core Rules" from RFC2234)

file = parameter-list / parameter-value-list
parameter-list = *(parameter CRLF)
parameter-value-list = *(parameter-value CRLF)
parameter-value = parameter WSP ":" value
parameter = 1*visible-except-colon
visible-except-colon = %x21-39 / %x3B-7E	; VCHAR - ":"
value = *VCHAR

> http://tools.ietf.org/id/draft-ietf-mmusic-rtsp-announce-01.txt

I would, in fact, prefer to see async stream event signalling in the
base spec. I think it is broadly useful.  But the ANNOUNCE draft
combines stream events with session announcements, and I don't see
async session announcements as being desirable in the base spec (does
anyone use them?), nor do I think the same method should be used for
both.

And I would rather see a finished, clean, extensible spec than my
preferred feature(s).  I do worry that extensions will be less
rigorously scrutinized because they are optional.

joe

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 09 May 2007 14:07:30 +0200

>> > for "text/parameters" despite its usage both in the field and in the

I didn't respond to the question about content type negotiation. I have 
logged a bug for this so we don't forget it. However shouldn't it be 
possible to specify it so that the Accept header can be used with 
GET_PARAMETER. To me it also seems that feature tags can be used to 
express a set of capabilities that include parameter format and the 
usage of SET or GET Parameter.

However to my understanding the usage for these method has usually to do 
with particular application usages. For example 3GPP uses them for 
reporting quality of experience measurement. In these cases you have 
another specification that defines what type shall be used in the 
method. Thus it is interoperable within certain context.

> visible-except-colon = %x21-39 / %x3B-7E    ; VCHAR - ":"

Thanks, it is at least a start. There is also need for a media type. I 
updated the bug I had from EKR's review to include your comments also.

> anyone use them?), nor do I think the same method should be used for

Okay, that seems like a very valid comment. I know that a common feature 
request is the inclusion of End of stream signalling. While the need for 
session announcements hasn't been as widely needed. But there has been 
expressed interest also in that.

> rigorously scrutinized because they are optional.

I agree about finishing things up. That is why any new feature will need 
to have proponents that are willing to contribute with text that 
basically can be cut and past into the spec for their feature. Otherwise 
we are very likely to leave things out. Unless we deem them critical to 
make things work. For example END_OF_STREAM is nice to have but not 
necessary.

I am not certain that extensions would receive less scrutiny then things 
added to the base spec.

Cheers

Magnus Westerlund