On 2013-06-07 17:40, Elwyn Davies wrote: > 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.
Yes, I think this negotiation should happen on per methods basis. >> >> 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. Sure, I personally don't have any issue with making it at least SHOULD implement text/parameters. But from my horizon a forward pointer with the normative requirements is sufficient to accomplish that. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerl...@ericsson.com ----------------------------------------------------------------------
