Section 9. Message Body

Some request and response messages include a message body, if not
   otherwise restricted by the request method or response status code.
   The message body consists of the content data itself (see also
   Section 5.3).
   The SET_PARAMETER and GET_PARAMETER requests and responses, and the
   DESCRIBE response as defined by this specification, can have a
   message body; the purpose of the message body is defined in each
   case.  All 4xx and 5xx responses MAY also have a message body to
   carry additional response information.  Generally, a message body MAY
   be attached to any RTSP 2.0 request or response, but the content of
   the message body MAY be ignored by the receiver.  Extensions to this
   specification can specify the purpose and content of message bodies,
   including requiring their inclusion.
   In this section, both sender and recipient refer to either the client
   or the server, depending on who sends and who receives the message
   body.
9.1.  Message Body Header Fields
   Message body header fields define meta-information about the content
   data in the message body.  The message body header fields are listed
   in Table 6.
                   +------------------+----------------+
                   | Header           | Defined in     |
                   +------------------+----------------+
                   | Allow            | Section 18.6   |
                   |                  |                |
                   | Content-Base     | Section 18.14  |
                   |                  |                |
                   | Content-Encoding | Section 18.15  |
                   |                  |                |
                   | Content-Language | Section 18.16  |
                   |                  |                |
                   | Content-Length   | Section 18.17  |
                   |                  |                |
                   | Content-Location | Section 18.18  |
                   |                  |                |
                   | Content-Type     | Section 18.19  |
                   |                  |                |
                   | Expires          | Section 18.22  |
                   |                  |                |
                   | Last-Modified    | Section 18.27  |
                   +------------------+----------------+
                  Table 6: The RTSP Message Body Headers
   The extension-header mechanism allows additional message body header
   fields to be defined without changing the protocol, but these fields
   cannot be assumed to be recognizable by the recipient.  Unrecognized
   header fields MUST be ignored by the recipient and forwarded by
   proxies.
9.2.  Message Body
   An RTSP message with a message body MUST include the Content-Type and
   Content-Length headers.  When a message body is included with a
   message, the data type of that content data is determined via the
   Content-Type and Content-Encoding header fields.
   Content-Type specifies the media type of the underlying data.  There
   is no default media format and the actual format used in the body is
   required to be explicitly stated in the Content-Type header.  By
   being explicit and always requiring the inclusion of the Content-Type
   header with accurate information, one avoids the many pitfalls in a
   heuristic-based interpretation of the body content.  The user
   experience of HTTP and email have suffered from relying on such
   heuristics.
   Content-Encoding may be used to indicate any additional content-
   codings applied to the data, usually for the purpose of data
   compression, that are a property of the requested resource.  The
   default encoding is 'identity', i.e. no transformation of the message
   body.
   The Content-Length of a message is the length of the content,
   measured in octets.
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.