Subject: [MMUSIC] Usage of Accept header in GET- and SET-PARAMETER

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Sep 2016 13:59:16 +0200

Hi,

In my AUTH48 review I found one issue around Accept header and 
GET_PARAMETER and SET_PARAMETER that I think the WG needs to know of and 
provide input on.

So lets start with what Accept says:

18.1.  Accept

    The Accept request-header field can be used to specify certain
    presentation description and parameter media types [RFC6838] that are
    acceptable for the response to DESCRIBE and GET_PARAMETER requests.

My first reflection was what about SET_PARAMETER? And then I review what 
SET and GET parameter actually says. The issue is that as when one want 
to use message body in GET and SET one can't do it without including the 
message body in the request. Thus Accept's pattern does not work. Accept 
works fine for DESCRIBE, where one requests a resource and the response 
message body must be one which the requesting agent supports. For how we 
defined SET and GET_PARAMETER the requesting agent needs to know that 
the responding entity supports the format. This makes me conclude that 
Accept header can't be used with GET_PARAMETER or SET_PARAMETER.

Thus, I think the easiest way forward is simply to remove the existing 
indications that Accept header can be used with either.

Please provide feedback in the next two weeks (no later than 20th of 
September).

/Magnus

Below you find relevant Excepts from the spec:

GET_PARAMETER says:

    The other way is to specify a message body that lists the
    parameter(s) that are desired to be retrieved.  The Content-Type
    header (Section 18.19) is used to specify which format the message
    body has.  If the receiver of the request does not support the media
    type used for the message body, it SHALL respond using the error code
    415 (Unsupported Media Type).  The responder to a GET_PARAMETER
    request MUST use the media type of the request for the response.  For
    additional considerations regarding message body negotiation, see
    Section 9.3.

    RTSP agents implementing support for responding to GET_PARAMETER
    requests SHALL implement the "text/parameters" format (Appendix F).
    This to ensure that at least one known format for parameters is
    implemented and, thus, prevent parameter format negotiation failure.

SET_PARAMETER says:

   When using a message body to list the parameter(s) desired to be set,
    the Content-Type header (Section 18.19) is used to specify which
    format the message body has.  If the receiver of the request is not
    supporting the media type used for the message body, it SHALL respond
    using the error code 415 (Unsupported Media Type).  For additional
    considerations regarding message body negotiation, see Section 9.3.

    RTSP agents implementing support for responding to SET_PARAMETER
    requests SHALL implement the text/parameters format (Appendix F).
    This is to ensure that at least one known format for parameters is
    implemented and, thus, prevent parameter format negotiation failure.

9.3.  Message Body Format Negotiation

    The content format of the message body is provided using the Content-
    Type header (Section 18.19).  To enable the responder of a request to
    determine which media type it should use, the requester may include
    the Accept header (Section 18.1) in a request to identify supported
    media types or media type ranges suitable to the response.  In case
    the responder is not supporting any of the specified formats, then
    the request response will be a 406 (Not Acceptable) error code.

    The media types that may be used on requests with message bodies need
    to be determined through the use of feature-tags, specification
    requirement, or trial and error.  Trial and error works because when
    the responder does not support the media type of the message body, it
    will respond with a 415 (Unsupported Media Type).

    The formats supported and their negotiation is done individually on a
    per method and direction (request or response body) direction.
    Requirements on supporting particular media types for use as message
    bodies in requests and response SHALL also be specified on a per-
    method and per-direction basis.

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 6 Sep 2016 14:42:18 +0200

Hi,

This is for RTSP 2.0:
https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc2326bis/

/Magnus

-- 

Magnus Westerlund

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 06 Sep 2016 10:32:17 -0500

Adding Alissa, since she still holds the AD token for this one (we 
grandfathered it when I became responsible for MMUSIC).

On 6 Sep 2016, at 6:59, Magnus Westerlund wrote:

> GET_PARAMETER and SET_PARAMETER that I think the WG needs to know of 
> and provide input on.
>
> My first reflection was what about SET_PARAMETER? And then I review 
> what SET and GET parameter actually says. The issue is that as when 
> one want to use message body in GET and SET one can't do it without 
> including the message body in the request. Thus Accept's pattern does 
> not work. Accept works fine for DESCRIBE, where one requests a 
> resource and the response message body must be one which the 
> requesting agent supports. For how we defined SET and GET_PARAMETER 
> the requesting agent needs to know that the responding entity supports 
> the format. This makes me conclude that Accept header can't be used 
> with GET_PARAMETER or SET_PARAMETER.
>