Hi Elwyn, On 2013-06-07 14:26, Elwyn Davies wrote: > On Fri, 2013-06-07 at 11:35 +0200, Magnus Westerlund wrote: >> Hi Elwyn, >> >> Many thanks for the detailed review. We will address the nits you have >> raised, but I cut them out of this reply to focus on the more >> substantial issues you have brought up. > .. and thanks for the quick response. > >> >> See inline below. > OK. I think the responses clear those issues. > > I have done a little bit more on the Appendices and liaised a bit with > Robert Sparks. 'Highlights': > > 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. 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. > > Appendix B: I appreciate that the state machine is illustrative and to > an extent 'abstract'. However, the tables are really written to > describe the state machine in the server: the action column mostly > describes the events that come into the server (apart from the notify > actions) - sending these 'events' are actions in the client. The 'real' > state machine in the both the server and the client has a somewhat more > complex form: I'd think that there was a STOPPED state in the server > when the media has reached an end point and not been explictly paused > and STARTING/PAUSING states in the client while the client waits for > response to PLAY/PAUSE respectively. I think a little bit more > explanation about the dual nature of the columns would solve the > problem. There shouldn't be an issue to clarify this nature. 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.westerlund@xxxxxxxxxxxx ----------------------------------------------------------------------