On Fri, 2013-06-07 at 16:05 +0200, Magnus Westerlund wrote: > > Appendix F: I missed that the text/parameter format appeared in the > > examples for GET_PARAMETER and SET_PARAMETER. It isn't stated in the > > definitions of these methods what encodings are acceptable for the > > message bodies that may go with these methods and their responses. > > Exactly, that is intentional. These methods can use anything that has a > MIME type. Also it has HTTP's mechanisms for determining what formats > one supports. > > > Clearly the new text/parameter MIME format is one. Is it the only one? > > It is the only one defined by IETF for this purpose. That is why it is > in the appendix so that RTSP users shall have something to define the > parameters they want in. However, they have to accept the limitations of > a basic text format. > > > I guess you could use a application/json or an XML format but I guess > > these would also either have to be called out explicitly in the method > > descriptions or put in as feature extensions. This needs to be > > clarified in the method descriptions (s13). The upshot of all this is > > that I think Appendix F needs to be pulled back into Section 20 as > > currently it is the only way to encode the message bodies. > > I can agree that the format negotiation for the bodies of > GET/SET_PARAMETER is not clear. I will look at proposing some > improvements of the text related to the handling of method bodies and > their format negotiation. Good. I don't see where the server tells what formats it accepts for either GET_PARAMETER or SET_PARAMETER. Also the Accept spec doesn't say anything about SET_PARAMETER. AFAICS the client could tell the server what formats it accepts as a side-effect of DESCRIBE but that's a bit arcane - and it is not clear how you would separate the formats for DESCRIBE from those for GET_PARAM and SET_PARAM. > > However, I am not pulling in Appendix F. It is an optional to use format > for parameter value pairs that can be used in these methods, it is not > required. Nor, does the specification define any parameters that are > transferred using this interface. The things that are in the appendix > are not core protocol, they represent either informational things, like > the examples and the state machine. The other appendices are normative > definitions of particular choices for things that can be combined or > used with RTSP, like RTP as media transport. > OK, it is possible to use GET_PARAM for basic requirements without using message bodies, so you can get away without defining a lowest common denominator format. However, the use of message bodies for SET_PARAM is RECOMMENDED so it seems a little odd not to ensure that server and client will have at least one format in common. (And its not as if we are dealing with a hugely complicated bit of spec for text/parameters! :-) ). Then, given the example in GET_PARAMETER it seems sensible to advise implementing text/parameters as the default for GET_PARAM also.
/Elwyn
