Re: [MMUSIC] RTSP: Speed header

[Magnus Westerlund <[e-mail]>]

Joseph Pallas skrev:
> On 5/7/07, Magnus Westerlund <[e-mail]> wrote:
>>    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 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.

>>
>> Yes, I agree with that this isn't complete. Are you willing to write an
>> 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

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.

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

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.

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

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

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM/M
----------------------------------------------------------------------
Ericsson AB                | Phone [phone]
Torshamsgatan 23           | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: [e-mail]
----------------------------------------------------------------------

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