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