Re: [Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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







[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]