Section 11. Capability Handling

This section describes the available capability-handling mechanism
   that allows RTSP to be extended.  Extensions to this version of the
   protocol are basically done in two ways.  Firstly, new headers can be
   added.  Secondly, new methods can be added.  The capability-handling
   mechanism is designed to handle both cases.
   When a method is added, the involved parties can use the OPTIONS
   method to discover whether it is supported.  This is done by issuing
   an OPTIONS request to the other party.  Depending on the URI, it will
   either apply in regard to a certain media resource, the whole server
   in general, or simply the next hop.  The OPTIONS response MUST
   contain a Public header that declares all methods supported for the
   indicated resource.
   It is not necessary to use OPTIONS to discover support of a method,
   as the client could simply try the method.  If the receiver of the
   request does not support the method, it will respond with an error
   code indicating the method is either not implemented (501) or does
   not apply for the resource (405).  The choice between the two
   discovery methods depends on the requirements of the service.
   Feature tags are defined to handle functionality additions that are
   not new methods.  Each feature tag represents a certain block of
   functionality.  The amount of functionality that a feature tag
   represents can vary significantly.  For example, a feature tag can
   represent the functionality a single RTSP header provides.  Another
   feature tag can represent much more functionality, such as the
   "play.basic" feature tag (Section 11.1), which represents the minimal
   media delivery for playback implementation.
   Feature tags are used to determine whether the client, server, or
   proxy supports the functionality that is necessary to achieve the
   desired service.  To determine support of a feature tag, several
   different headers can be used, each explained below:
   Supported:  This header is used to determine the complete set of
         functionality that both client and server have, in general, and
         is not dependent on a specific resource.  The intended usage is
         to determine before one needs to use a functionality that it is
         supported.  It can be used in any method, but OPTIONS is the
         most suitable as it simultaneously determines all methods that
         are implemented.  When sending a request, the requester
         declares all its capabilities by including all supported
         feature tags.  This results in the receiver learning the
         requester's feature support.  The receiver then includes its
         set of features in the response.
   Proxy-Supported:  This header is used in a similar fashion as the
         Supported header, but instead of giving the supported
         functionality of the client or server, it provides both the
         requester and the responder a view of the common functionality
         supported in general by all members of the proxy chain between
         the client and server; it does not depend on the resource.
         Proxies are required to add this header whenever the Supported
         header is present, but proxies may also add it independently of
         the requester.
   Require:  This header can be included in any request where the
         endpoint, i.e., the client or server, is required to understand
         the feature to correctly perform the request.  This can, for
         example, be a SETUP request, where the server is required to
         understand a certain parameter to be able to set up the media
         delivery correctly.  Ignoring this parameter would not have the
         desired effect and is not acceptable.  Therefore, the endpoint
         receiving a request containing a Require MUST negatively
         acknowledge any feature that it does not understand and not
         perform the request.  The response in cases where features are
         not supported is 551 (Option Not Supported).  Also, the
         features that are not supported are given in the Unsupported
         header in the response.
   Proxy-Require:  This header has the same purpose and behavior as
         Require except that it only applies to proxies and not the
         endpoint.  Features that need to be supported by both proxies
         and endpoints need to be included in both the Require and
         Proxy-Require header.
   Unsupported:  This header is used in a 551 (Option Not Supported)
         error response, to indicate which features were not supported.
         Such a response is only the result of the usage of the Require
         or Proxy-Require headers where one or more features were not
         supported.  This information allows the requester to make the
         best of situations as it knows which features are not
         supported.
11.1.  Feature Tag: play.basic
   An implementation supporting all normative parts of this
   specification for the setup and control of playback of media uses the
   feature tag "play.basic" to indicate this support.  The appendices
   (starting with letters) are not part of the functionality included in
   the feature tag unless the appendix is explicitly specified in a main
   section as being a required appendix.
      Note: This feature tag does not mandate any media delivery
      protocol, such as RTP.
      In RTSP 1.0, there was a minimal implementation section.  However,
      that was not consistent with the rest of the specification.  So,
      rather than making an attempt to explicitly enumerate the features
      for play.basic, this specification has to be taken as a whole and
      the necessary features normatively defined as being required are
      included.