Section 22. IANA Considerations

This section describes a number of registries for RTSP 2.0 that have
   been established and are maintained by IANA.  These registries are
   separate from any registries existing for RTSP 1.0.  For each
   registry, there is a description of the required content, the
   registration procedures, and the entries that this document
   registers.  For more information on extending RTSP, see Section 2.7.
   In addition, this document registers three SDP attributes.
   Registries or entries in registries that have been made for RTSP 1.0
   are not moved to RTSP 2.0: the registries and entries of RTSP 1.0 and
   RTSP 2.0 are independent.  If any registry or entry in a registry is
   also required in RTSP 2.0, it MUST follow the procedure defined below
   to allocate the registry or entry in a registry.
   The sections describing how to register an item use some of the
   registration policies described in [RFC5226] -- namely, "First Come
   First Served", "Expert Review", "Specification Required", and
   "Standards Action".
   In case a registry requires a contact person, the authors (with
   Magnus Westerlund <magnus.westerlund@ericsson.com> as primary) are
   the contact persons for any entries created by this document.
   IANA will request the following information for any registration
   request:
   o  A name of the item to register according to the rules specified by
      the intended registry
   o  Indication of who has change control over the feature (for
      example, the IETF, ISO, ITU-T, other international standardization
      bodies, a consortium, a particular company or group of companies,
      or an individual)
   o  A reference to a further description, if available, for example
      (in decreasing order of preference), an RFC, a published standard,
      a published paper, a patent filing, a technical report, documented
      source code or a computer manual
   o  For proprietary features, contact information (postal and email
      address)
22.1.  Feature Tags
22.1.1.  Description
   When a client and server try to determine what part and functionality
   of the RTSP specification and any future extensions that its
   counterpart implements, there is need for a namespace.  This registry
   contains named entries representing certain functionality.
   The usage of feature tags is explained in Section 11 and
   Section 13.1.
22.1.2.  Registering New Feature Tags with IANA
   The registering of feature tags is done on a First Come, First Served
   [RFC5226] basis.
   The registry entry for a feature tag has the following information:
   o  The name of the feature tag
      *  If the registrant indicates that the feature is proprietary,
         IANA should request a vendor "prefix" portion of the name.  The
         name will then be the vendor prefix followed by a "." followed
         by the rest of the provided feature name.
      *  If the feature is not proprietary, then IANA need not collect a
         prefix for the name.
   o  A one-paragraph description of what the feature tag represents
   o  The applicability (server, client, proxy, or some combination)
   o  A reference to a specification, if applicable
   Feature tag names (including the vendor prefix) may contain any non-
   space and non-control characters.  There is no length limit on
   feature tags.
   Examples for a vendor tag describing a proprietary feature are:
         vendorA.specfeat01
         vendorA.specfeat02
22.1.3.  Registered Entries
   The following feature tags are defined in this specification and
   hereby registered.  The change control belongs to the IETF.
   play.basic:  The implementation for delivery and playback operations
         according to the core RTSP specification, as defined in this
         memo.  Applies for clients, servers, and proxies.  See
         Section 11.1.
   play.scale:  Support of scale operations for media playback.  Applies
         only for servers.  See Section 18.46.
   play.speed:  Support of the speed functionality for media delivery.
         Applies only for servers.  See Section 18.50.
   setup.rtp.rtcp.mux:  Support of the RTP and RTCP multiplexing as
         discussed in Appendix C.1.6.4.  Applies for both client and
         servers and any media caching proxy.
   The IANA registry is a table with the name, description, and
   reference for each feature tag.
22.2.  RTSP Methods
22.2.1.  Description
   Methods are described in Section 13.  Extending the protocol with new
   methods allows for totally new functionality.
22.2.2.  Registering New Methods with IANA
   A new method is registered through a Standards Action [RFC5226]
   because new methods may radically change the protocol's behavior and
   purpose.
   A specification for a new RTSP method consists of the following
   items:
   o  A method name that follows the ABNF rules for methods.
   o  A clear specification of what a request using the method does and
      what responses are expected.  In which directions the method is
      used: C->S, S->C, or both.  How the use of headers, if any,
      modifies the behavior and effect of the method.
   o  A list or table specifying which of the IANA-registered headers
      that are allowed to be used with the method in the request or/and
      response.  The list or table SHOULD follow the format of tables in
      Section 18.
   o  Describe how the method relates to network proxies.
22.2.3.  Registered Entries
   This specification, RFC 7826, registers 10 methods: DESCRIBE,
   GET_PARAMETER, OPTIONS, PAUSE, PLAY, PLAY_NOTIFY, REDIRECT, SETUP,
   SET_PARAMETER, and TEARDOWN.  The initial table of the registry is
   provided below.
   Method         Directionality           Reference
   -----------------------------------------------------
   DESCRIBE       C->S                     RFC 7826
   GET_PARAMETER  C->S, S->C               RFC 7826
   OPTIONS        C->S, S->C               RFC 7826
   PAUSE          C->S                     RFC 7826
   PLAY           C->S                     RFC 7826
   PLAY_NOTIFY    S->C                     RFC 7826
   REDIRECT       S->C                     RFC 7826
   SETUP          C->S                     RFC 7826
   SET_PARAMETER  C->S, S->C               RFC 7826
   TEARDOWN       C->S, S->C               RFC 7826
22.3.  RTSP Status Codes
22.3.1.  Description
   A status code is the three-digit number used to convey information in
   RTSP response messages; see Section 8.  The number space is limited,
   and care should be taken not to fill the space.
22.3.2.  Registering New Status Codes with IANA
   A new status code registration follows the policy of IETF Review
   [RFC5226].  New RTSP functionality requiring Status Codes should
   first be registered in the range of x50-x99.  Only when the range is
   full should registrations be made in the x00-x49 range, unless it is
   to adopt an HTTP extension to RTSP.  This is done to enable any HTTP
   extension to be adopted to RTSP without needing to renumber any
   related status codes.  A specification for a new status code must
   include the following:
   o  The registered number.
   o  A description of what the status code means and the expected
      behavior of the sender and receiver of the code.
22.3.3.  Registered Entries
   RFC 7826 (this document) registers the numbered status code defined
   in the ABNF entry "Status-Code", except "extension-code" (that
   defines the syntax allowed for future extensions) in Section 20.2.2.
22.4.  RTSP Headers
22.4.1.  Description
   By specifying new headers, one or more methods can be enhanced in
   many different ways.  An unknown header will be ignored by the
   receiving agent.  If the new header is vital for certain
   functionality, a feature tag for the functionality can be created and
   demanded to be used by the counterpart with the inclusion of a
   Require header carrying the feature tag.
22.4.2.  Registering New Headers with IANA
   Registrations can be made following the Expert Review policy
   [RFC5226].  A specification is recommended to be provided, preferably
   an RFC or other specification from a Standards Developing
   Organization.  The minimal information in a registration request is
   the header name and the contact information.
   The expert reviewer verifies that the registration request contains
   the following information:
   o  The name of the header.
   o  An ABNF specification of the header syntax.
   o  A list or table specifying when the header may be used,
      encompassing all methods, their request or response, and the
      direction (C->S or S->C).
   o  How the header is to be handled by proxies.
   o  A description of the purpose of the header.
22.4.3.  Registered Entries
   All headers specified in Section 18 in RFC 7826 have been registered.
   The registry includes the header name and reference.
   Furthermore, the following legacy RTSP headers defined in other
   specifications are registered with header name, and reference
   according to below list.  Note: these references may not fulfill all
   of the above rules for registrations due to their legacy status.
   o  x-wap-profile defined in [TS-26234].  The x-wap-profile request-
      header contains one or more absolute URLs to the requesting
      agent's device-capability profile.
   o  x-wap-profile-diff defined in [TS-26234].  The x-wap-profile-diff
      request-header contains a subset of a device-capability profile.
   o  x-wap-profile-warning defined in [TS-26234].  The x-wap-profile-
      warning is a response-header that contains error codes explaining
      to what extent the server has been able to match the terminal
      request in regard to device-capability profiles, as described
      using x-wap-profile and x-wap-profile-diff headers.
   o  x-predecbufsize defined in [TS-26234].  This response-header
      provides an RTSP agent with the TS 26.234 Annex G hypothetical
      pre-decoder buffer size.
   o  x-initpredecbufperiod defined in [TS-26234].  This response-header
      provides an RTSP agent with the TS 26.234 Annex G hypothetical
      pre-decoder buffering period.
   o  x-initpostdecbufperiod defined in [TS-26234].  This response-
      header provides an RTSP agent with the TS 26.234 Annex G post-
      decoder buffering period.
   o  3gpp-videopostdecbufsize defined in [TS-26234].  This response-
      header provides an RTSP agent with the TS 26.234 defined post-
      decoder buffer size usable for H.264 (AVC) video streams.
   o  3GPP-Link-Char defined in [TS-26234].  This request-header
      provides the RTSP server with the RTSP client's link
      characteristics as determined from the radio interface.  The
      information that can be provided are guaranteed bitrate, maximum
      bitrate and maximum transfer delay.
   o  3GPP-Adaptation defined in [TS-26234].  This general-header is
      part of the bitrate adaptation solution specified for the Packet-
      switched Streaming Service (PSS).  It provides the RTSP client's
      buffer sizes and target buffer levels to the server, and responses
      are used to acknowledge the support and values.
   o  3GPP-QoE-Metrics defined in [TS-26234].  This general-header is
      used by PSS RTSP agents to negotiate the quality of experience
      metrics that a client should gather and report to the server.
   o  3GPP-QoE-Feedback defined in [TS-26234].  This request-header is
      used by RTSP clients supporting PSS to report the actual values of
      the metrics gathered in its quality of experience metering.
   The use of "x-" is NOT RECOMMENDED, but the above headers in the list
   were defined prior to the clarification.
22.5.  Accept-Credentials
   The security framework's TLS connection mechanism has two
   registerable entities.
22.5.1.  Accept-Credentials Policies
   This registry is for policies for an RTSP proxy's handling and
   verification of TLS certificates when establishing an outbound TLS
   connection on behalf of a client.  In Section 19.3.1, three policies
   for how to handle certificates are specified.  Further policies may
   be defined; registration is made through Standards Action [RFC5226].
   A registration request is required to contain the following
   information:
   o  Name of the policy.
   o  Text that describes how the policy works for handling the
      certificates.
   o  A contact person.
   This specification registers the following values:
   Any:  A policy requiring the proxy to accept any received
         certificate.
   Proxy:  A policy where the proxy applies its own policies to
         determine which certificates are accepted.
   User: A policy where the certificate is required to be forwarded down
         the proxy chain to the client, thus allowing the user to
         decided to accept or refuse a certificate.
22.5.2.  Accept-Credentials Hash Algorithms
   The Accept-Credentials header (see Section 18.2) allows for the usage
   of other algorithms for hashing the DER records of accepted entities.
   The registration of any future algorithm is expected to be extremely
   rare and could also cause interoperability problems.  Therefore, the
   bar for registering new algorithms is intentionally placed high.
   Any registration of a new hash algorithm requires Standards Action
   [RFC5226].  The registration needs to fulfill the following
   requirement:
   o  The algorithms identifier meeting the "token" ABNF requirement.
   o  Provide a definition of the algorithm.
   The registered value is:
   Hash Alg. ID   Reference
   ------------------------
   sha-256        RFC 7826
22.6.  Cache-Control Cache Directive Extensions
   There exist a number of cache directives that can be sent in the
   Cache-Control header.  A registry for these cache directives has been
   established by IANA.  New registrations in this registry require
   Standards Action or IESG Approval [RFC5226].  A registration request
   needs to contain the following information.
   o  The name of the cache directive.
   o  A definition of the parameter value, if any is allowed.
   o  The specification if it is a request or response directive.
   o  Text that explains how the cache directive is used for RTSP-
      controlled media streams.
   o  A contact person.
   This specification registers the following values:
      no-cache:
      public:
      private:
      no-transform:
      only-if-cached:
      max-stale:
      min-fresh:
      must-revalidate:
      proxy-revalidate:
      max-age:
   The registry contains the name of the directive and the reference.
22.7.  Media Properties
22.7.1.  Description
   The media streams being controlled by RTSP can have many different
   properties.  The media properties required to cover the use cases
   that were in mind when writing the specification are defined.
   However, it can be expected that further innovation will result in
   new use cases or media streams with properties not covered by the
   ones specified here.  Thus, new media properties can be specified.
   As new media properties may need a substantial amount of new
   definitions to correctly specify behavior for this property, the bar
   is intended to be high.
22.7.2.  Registration Rules
   Registering a new media property is done following the Specification
   Required policy [RFC5226].  The expert reviewer verifies that a
   registration request fulfills the following requirements.
   o  An ABNF definition of the media property value name that meets
      "media-prop-ext" definition is included.
   o  A definition of which media property group it belongs to or define
      a new group is included.
   o  A description of all changes to the behavior of RTSP as result of
      these changes is included.
   o  A contact person for the registration is listed.
22.7.3.  Registered Values
   This specification registers the ten values listed in Section 18.29.
   The registry contains the property group, the name of the media
   property, and the reference.
22.8.  Notify-Reason Values
22.8.1.  Description
   Notify-Reason values are used to indicate the reason the notification
   was sent.  Each reason has its associated rules on what headers and
   information may or must be included in the notification.  New
   notification behaviors need to be specified to enable interoperable
   usage; thus, a specification of each new value is required.
22.8.2.  Registration Rules
   Registrations for new Notify-Reason values follow the Specification
   Required policy [RFC5226].  The expert reviewer verifies that the
   request fulfills the following requirements:
   o  An ABNF definition of the Notify-Reason value name that meets
      "Notify-Reason-extension" definition is included.
   o  A description of which headers shall be included in the request
      and response, when it should be sent, and any effect it has on the
      server client state is made clear.
   o  A contact person for the registration is listed.
22.8.3.  Registered Values
   This specification registers three values defined in the Notify-Reas-
   val ABNF, Section 20.2.3:
   end-of-stream:  This Notify-Reason value indicates the end of a media
      stream.
   media-properties-update:  This Notify-Reason value allows the server
      to indicate that the properties of the media have changed during
      the playout.
   scale-change:  This Notify-Reason value allows the server to notify
      the client about a change in the scale of the media.
   The registry contains the name, description, and reference.
22.9.  Range Header Formats
22.9.1.  Description
   The Range header (Section 18.40) allows for different range formats.
   These range formats also need an identifier to be used in the Accept-
   Ranges header (Section 18.5).  New range formats may be registered,
   but moderation should be applied as it makes interoperability more
   difficult.
22.9.2.  Registration Rules
   A registration follows the Specification Required policy [RFC5226].
   The expert reviewer verifies that the request fulfills the following
   requirements:
   o  An ABNF definition of the range format that fulfills the "range-
      ext" definition is included.
   o  The range format identifier used in Accept-Ranges header according
      to the "extension-format" definition is defined.
   o  Rules for how one handles the range when using a negative Scale
      are included.
   o  A contact person for the registration is listed.
22.9.3.  Registered Values
   The registry contains the Range header format identifier, the name of
   the range format, and the reference.  This specification registers
   the following values.
   npt:  Normal Play Time
   clock:  UTC Absolute Time format
   smpte:  SMPTE Timestamps
   smpte-30-drop:  SMPTE Timestamps 29.97 Frames/sec (30 Hz with Drop)
   smpte-25:  SMPTE Timestamps 25 Frames/sec
22.10.  Terminate-Reason Header
   The Terminate-Reason header (Section 18.52) has two registries for
   extensions.
22.10.1.  Redirect Reasons
   This registry contains reasons for session termination that can be
   included in a Terminate-Reason header (Section 18.52).  Registrations
   follow the Expert Review policy [RFC5226].  The expert reviewer
   verifies that the registration request contains the following
   information:
   o  That the value follows the Terminate-Reason ABNF, i.e., be a
      token.
   o  That the specification provide a definition of what procedures are
      to be followed when a client receives this redirect reason.
   o  A contact person
   This specification registers three values:
   o  Session-Timeout
   o  Server-Admin
   o  Internal-Error
   The registry contains the name of the Redirect Reason and the
   reference.
22.10.2.  Terminate-Reason Header Parameters
   This registry contains parameters that may be included in the
   Terminate-Reason header (Section 18.52) in addition to a reason.
   Registrations are made under the Specification Required policy
   [RFC5226].  The expert reviewer verifies that the registration
   request contains the following:
   o  A parameter name.
   o  A parameter following the syntax allowed by the RTSP 2.0
      specification.
   o  A reference to the specification.
   o  A contact person.
   This specification registers:
   o  time
   o  user-msg
   The registry contains the name of the Terminate Reason and the
   reference.
22.11.  RTP-Info Header Parameters
22.11.1.  Description
   The RTP-Info header (Section 18.45) carries one or more parameter
   value pairs with information about a particular point in the RTP
   stream.  RTP extensions or new usages may need new types of
   information.  As RTP information that could be needed is likely to be
   generic enough, and to maximize the interoperability, new
   registration is made under the Specification Required policy.
22.11.2.  Registration Rules
   Registrations for new RTP-Info values follow the policy of
   Specification Required [RFC5226].  The expert reviewer verifies that
   the registration request contains the following information.
   o  An ABNF definition that meets the "generic-param" definition.
   o  A reference to the specification.
   o  A contact person for the registration.
22.11.3.  Registered Values
   This specification registers the following parameter value pairs:
   o  url
   o  ssrc
   o  seq
   o  rtptime
   The registry contains the name of the parameter and the reference.
22.12.  Seek-Style Policies
22.12.1.  Description
   Seek-Style policy defines how the RTSP agent seeks in media content
   when given a position within the media content.  New seek policies
   may be registered; however, a large number of these will complicate
   implementation substantially.  The impact of unknown policies is that
   the server will not honor the unknown and will use the server default
   policy instead.
22.12.2.  Registration Rules
   Registrations of new Seek-Style policies follow the Specification
   Required policy [RFC5226].  The expert reviewer verifies that the
   registration request fulfills the following requirements:
   o  Has an ABNF definition of the Seek-Style policy name that meets
      "Seek-S-value-ext" definition.
   o  Includes a short description.
   o  Lists a contact person for the registration.
   o  Includes a description of which headers shall be included in the
      request and response, when it should be sent, and any affect it
      has on the server-client state.
22.12.3.  Registered Values
   This specification registers four values (Name - Short Description):
   o  RAP - Using the closest Random Access Point prior to or at the
      requested start position.
   o  CoRAP - Conditional Random Access Point is like RAP, but only if
      the RAP is closer prior to the requested start position than
      current pause point.
   o  First-Prior - The first-prior policy will start delivery with the
      media unit that has a playout time first prior to the requested
      start position.
   o  Next - The next media units after the provided start position.
   The registry contains the name of the Seek-Style policy, the
   description, and the reference.
22.13.  Transport Header Registries
   The transport header (Section 18.54) contains a number of parameters
   that have possibilities for future extensions.  Therefore, registries
   for these are defined below.
22.13.1.  Transport Protocol Identifier
   A Transport Protocol specification consists of a transport protocol
   identifier, representing some combination of transport protocols, and
   any number of transport header parameters required or optional to use
   with the identified protocol specification.  This registry contains
   the identifiers used by registered transport protocol identifiers.
   A registration for the parameter transport protocol identifier
   follows the Specification Required policy [RFC5226].  The expert
   reviewer verifies that the registration request fulfills the
   following requirements:
   o  A contact person or organization with address and email.
   o  A value definition that follows the ABNF syntax definition of
      "transport-id" Section 20.2.3.
   o  A descriptive text that explains how the registered values are
      used in RTSP, which underlying transport protocols are used, and
      any required Transport header parameters.
   The registry contains the protocol ID string and the reference.
   This specification registers the following values:
   RTP/AVP:  Use of the RTP [RFC3550] protocol for media transport in
         combination with the "RTP Profile for Audio and Video
         Conferences with Minimal Control" [RFC3551] over UDP.  The
         usage is explained in RFC 7826, Appendix C.1.
   RTP/AVP/UDP:  the same as RTP/AVP.
   RTP/AVPF:  Use of the RTP [RFC3550] protocol for media transport in
         combination with the "Extended RTP Profile for RTCP-based
         Feedback (RTP/AVPF)" [RFC4585] over UDP.  The usage is
         explained in RFC 7826, Appendix C.1.
   RTP/AVPF/UDP:  the same as RTP/AVPF.
   RTP/SAVP:  Use of the RTP [RFC3550] protocol for media transport in
         combination with the "The Secure Real-time Transport Protocol
         (SRTP)" [RFC3711] over UDP.  The usage is explained in RFC
         7826, Appendix C.1.
   RTP/SAVP/UDP:  the same as RTP/SAVP.
   RTP/SAVPF:  Use of the RTP [RFC3550] protocol for media transport in
         combination with the "Extended Secure RTP Profile for Real-time
         Transport Control Protocol (RTCP)-Based Feedback (RTP/SAVPF)"
         [RFC5124] over UDP.  The usage is explained in RFC 7826,
         Appendix C.1.
   RTP/SAVPF/UDP:  the same as RTP/SAVPF.
   RTP/AVP/TCP:  Use of the RTP [RFC3550] protocol for media transport
         in combination with the "RTP profile for audio and video
         conferences with minimal control" [RFC3551] over TCP.  The
         usage is explained in RFC 7826, Appendix C.2.2.
   RTP/AVPF/TCP:  Use of the RTP [RFC3550] protocol for media transport
         in combination with the "Extended RTP Profile for Real-time
         Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)"
         [RFC4585] over TCP.  The usage is explained in RFC 7826,
         Appendix C.2.2.
   RTP/SAVP/TCP:  Use of the RTP [RFC3550] protocol for media transport
         in combination with the "The Secure Real-time Transport
         Protocol (SRTP)" [RFC3711] over TCP.  The usage is explained in
         RFC 7826, Appendix C.2.2.
   RTP/SAVPF/TCP:  Use of the RTP [RFC3550] protocol for media transport
         in combination with the "Extended Secure RTP Profile for Real-
         time Transport Control Protocol (RTCP)-Based Feedback (RTP/
         SAVPF)" [RFC5124] over TCP.  The usage is explained in RFC
         7826, Appendix C.2.2.
22.13.2.  Transport Modes
   The Transport Mode is a Transport header (Section 18.54) parameter.
   It is used to identify the general mode of media transport.  The PLAY
   value registered defines a PLAYBACK mode, where media flows from
   server to client.
   A registration for the transport parameter mode follows the Standards
   Action policy [RFC5226].  The registration request needs to meet the
   following requirements:
   o  A value definition that follows the ABNF "token" definition
      Section 20.2.3.
   o  Text that explains how the registered value is used in RTSP.
   This specification registers one value:
   PLAY: See RFC 7826.
   The registry contains the transport mode value and the reference.
22.13.3.  Transport Parameters
   Transport Parameters are different parameters used in a Transport
   header's transport specification (Section 18.54) to provide
   additional information required beyond the transport protocol
   identifier to establish a functioning transport.
   A registration for parameters that may be included in the Transport
   header follows the Specification Required policy [RFC5226].  The
   expert reviewer verifies that the registration request fulfills the
   following requirements:
   o  A Transport Parameter Name following the "token" ABNF definition.
   o  A value definition, if the parameter takes a value, that follows
      the ABNF definition of "trn-par-value" Section 20.2.3.
   o  Text that explains how the registered value is used in RTSP.
   This specification registers all the transport parameters defined in
   Section 18.54.  This is a copy of that list:
   o  unicast
   o  multicast
   o  interleaved
   o  ttl
   o  layers
   o  ssrc
   o  mode
   o  dest_addr
   o  src_addr
   o  setup
   o  connection
   o  RTCP-mux
   o  MIKEY
   The registry contains the transport parameter name and the reference.
22.14.  URI Schemes
   This specification updates two URI schemes: one previously
   registered, "rtsp", and one missing in the registry, "rtspu"
   "rtsps", is also registered.  These URI schemes are registered in an
   existing registry ("Uniform Resource Identifier (URI) Schemes") not
   created by this memo.  Registrations follow [RFC7595].
22.14.1.  The "rtsp" URI Scheme
   URI scheme name:  rtsp
   Status:  Permanent
   URI scheme syntax:  See Section 20.2.1 of RFC 7826.
   URI scheme semantics:  The rtsp scheme is used to indicate resources
         accessible through the usage of the Real-Time Streaming
         Protocol (RTSP).  RTSP allows different operations on the
         resource identified by the URI, but the primary purpose is the
         streaming delivery of the resource to a client.  However, the
         operations that are currently defined are DESCRIBE,
         GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
         SETUP, SET_PARAMETER, and TEARDOWN.
   Encoding considerations:  IRIs in this scheme are defined and need to
         be encoded as RTSP URIs when used within RTSP.  That encoding
         is done according to RFC 3987.
   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
   Interoperability considerations:  The extensions in the URI syntax
         performed between RTSP 1.0 and 2.0 can create interoperability
         issues.  The changes are:
            Support for IPv6 literals in the host part and future IP
            literals through a mechanism as defined in RFC 3986.
            A new relative format to use in RTSP elements that is not
            required to start with "/".
         The above changes should have no impact on interoperability as
         discussed in detail in Section 4.2 of RFC 7826.
   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 also apply to this scheme.  They need to
         be reviewed and considered in any implementation utilizing this
         scheme.
   Contact:  Magnus Westerlund, magnus.westerlund@ericsson.com
   Author/Change controller:  IETF
   References:  RFC 2326, RFC 3986, RFC 3987, and RFC 7826
22.14.2.  The "rtsps" URI Scheme
   URI scheme name:  rtsps
   Status:  Permanent
   URI scheme syntax:  See Section 20.2.1 of RFC 7826.
   URI scheme semantics:  The rtsps scheme is used to indicate resources
         accessible through the usage of the Real-Time Streaming
         Protocol (RTSP) over TLS.  RTSP allows different operations on
         the resource identified by the URI, but the primary purpose is
         the streaming delivery of the resource to a client.  However,
         the operations that are currently defined are DESCRIBE,
         GET_PARAMETER, OPTIONS, PLAY, PLAY_NOTIFY, PAUSE, REDIRECT,
         SETUP, SET_PARAMETER, and TEARDOWN.
   Encoding considerations:  IRIs in this scheme are defined and need to
         be encoded as RTSP URIs when used within RTSP.  That encoding
         is done according to RFC 3987.
   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
   Interoperability considerations:  The "rtsps" scheme was never
         officially defined for RTSP 1.0; however, it has seen
         widespread use in actual deployments of RTSP 1.0.  Therefore,
         this section discusses the believed changes between the
         unspecified RTSP 1.0 "rtsps" scheme and RTSP 2.0 definition.
         The extensions in the URI syntax performed between RTSP 1.0 and
         2.0 can create interoperability issues.  The changes are:
            Support for IPv6 literals in the host part and future IP
            literals through a mechanism as defined by RFC 3986.
            A new relative format to use in RTSP elements that is not
            required to start with "/".
         The above changes should have no impact on interoperability as
         discussed in detail in Section 4.2 of RFC 7826.
   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 also apply to this scheme.  They need to
         be reviewed and considered in any implementation utilizing this
         scheme.
   Contact:  Magnus Westerlund, magnus.westerlund@ericsson.com
   Author/Change controller:  IETF
   References:  RFC 2326, RFC 3986, RFC 3987, and RFC 7826
22.14.3.  The "rtspu" URI Scheme
   URI scheme name:  rtspu
   Status:  Permanent
   URI scheme syntax:  See Section 3.2 of RFC 2326.
   URI scheme semantics:  The rtspu scheme is used to indicate resources
         accessible through the usage of the Real-Time Streaming
         Protocol (RTSP) over unreliable datagram transport.  RTSP
         allows different operations on the resource identified by the
         URI, but the primary purpose is the streaming delivery of the
         resource to a client.  However, the operations that are
         currently defined are DESCRIBE, GET_PARAMETER, OPTIONS,
         REDIRECT,PLAY, PLAY_NOTIFY, PAUSE, SETUP, SET_PARAMETER, and
         TEARDOWN.
   Encoding considerations:  This scheme is not intended to be used with
         characters outside the US-ASCII repertoire.
   Applications/protocols that use this URI scheme name:  RTSP 1.0 (RFC
         2326).
   Interoperability considerations:  The definition of the transport
         mechanism of RTSP over UDP has interoperability issues.  That
         makes the usage of this scheme problematic.
   Security considerations:  All the security threats identified in
         Section 7 of RFC 3986 also apply to this scheme.  They need to
         be reviewed and considered in any implementation utilizing this
         scheme.
   Contact:  Magnus Westerlund, magnus.westerlund@ericsson.com
   Author/Change controller:  IETF
   References:  RFC 2326
22.15.  SDP Attributes
   This specification defines three SDP [RFC4566] attributes that have
   been registered by IANA.
   SDP Attribute ("att-field"):
        Attribute name:     range
        Long form:          Media Range Attribute
        Type of name:       att-field
        Type of attribute:  both session and media level
        Subject to charset: No
        Purpose:            RFC 7826
        Reference:          RFC 2326, RFC 7826
        Values:             See ABNF definition.
        Attribute name:     control
        Long form:          RTSP control URI
        Type of name:       att-field
        Type of attribute:  both session and media level
        Subject to charset: No
        Purpose:            RFC 7826
        Reference:          RFC 2326, RFC 7826
        Values:             Absolute or Relative URIs.
        Attribute name:     mtag
        Long form:          Message Tag
        Type of name:       att-field
        Type of attribute:  both session and media level
        Subject to charset: No
        Purpose:            RFC 7826
        Reference:          RFC 7826
        Values:             See ABNF definition
22.16.  Media Type Registration for text/parameters
   Type name:  text
   Subtype name:  parameters
   Required parameters:
   Optional parameters:  charset: The charset parameter is applicable to
      the encoding of the parameter values.  The default charset is
      UTF-8, if the 'charset' parameter is not present.
   Encoding considerations:  8bit
   Security considerations:  This format may carry any type of
      parameters.  Some can have security requirements, like privacy,
      confidentiality, or integrity requirements.  The format has no
      built-in security protection.  For the usage, the transport can be
      protected between server and client using TLS.  However, care must
      be taken to consider if the proxies are also trusted with the
      parameters in case hop-by-hop security is used.  If stored as a
      file in a file system, the necessary precautions need to be taken
      in relation to the parameter requirements including object
      security such as S/MIME [RFC5751].
   Interoperability considerations:  This media type was mentioned as a
      fictional example in [RFC2326], but was not formally specified.
      This has resulted in usage of this media type that may not match
      its formal definition.
   Published specification:  RFC 7826, Appendix F.
   Applications that use this media type:  Applications that use RTSP
      and have additional parameters they like to read and set using the
      RTSP GET_PARAMETER and SET_PARAMETER methods.
   Additional information:
   Magic number(s):  N/A
   File extension(s):  N/A
   Macintosh file type code(s):  N/A
   Person & email address to contact for further information:
      Magnus Westerlund (magnus.westerlund@ericsson.com)
   Intended usage:   Common
   Restrictions on usage:   None
   Author:  Magnus Westerlund (magnus.westerlund@ericsson.com)
   Change controller:  IETF
   Addition Notes: