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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------