zilinlin/RFC2PSM huggingface dataset:
Section 1. Introduction

This memo defines version 2.0 of the Real-Time Streaming Protocol
   (RTSP 2.0).  RTSP 2.0 is an application-layer protocol for the setup
   and control over the delivery of data with real-time properties,
   typically streaming media.  Streaming media is, for instance, video
   on demand or audio live streaming.  Put simply, RTSP acts as a
   "network remote control" for multimedia servers.
   The protocol operates between RTSP 2.0 clients and servers, but it
   also supports the use of proxies placed between clients and servers.
   Clients can request information about streaming media from servers by
   asking for a description of the media or use media description
   provided externally.  The media delivery protocol is used to
   establish the media streams described by the media description.
   Clients can then request to play out the media, pause it, or stop it
   completely.  The requested media can consist of multiple audio and
   video streams that are delivered as time-synchronized streams from
   servers to clients.
   obsoletes that specification.  This protocol is based on RTSP 1.0 but
   is not backwards compatible other than in the basic version
   negotiation mechanism.  The changes between the two documents are
   listed in Appendix I.  There are many reasons why RTSP 2.0 can't be
   backwards compatible with RTSP 1.0; some of the main ones are as
   follows:
   o  Most headers that needed to be extensible did not define the
      allowed syntax, preventing safe deployment of extensions;
   o  the changed behavior of the PLAY method when received in Play
      state;
   o  the changed behavior of the extensibility model and its mechanism;
      and
   o  the change of syntax for some headers.
   There are so many small updates that changing versions became
   necessary to enable clarification and consistent behavior.  Anyone
   implementing RTSP for a new use case in which they have not installed
   RTSP 1.0 should only implement RTSP 2.0 to avoid having to deal with
   RTSP 1.0 inconsistencies.
   This document is structured as follows.  It begins with an overview
   of the protocol operations and its functions in an informal way.
   Then, a set of definitions of terms used and document conventions is
   introduced.  These are followed by the actual RTSP 2.0 core protocol
   specification.  The appendices describe and define some
   functionalities that are not part of the core RTSP specification, but
   which are still important to enable some usages.  Among them, the RTP
   usage is defined in Appendix C, the Session Description Protocol
   (SDP) usage with RTSP is defined in Appendix D, and the "text/
   parameters" file format Appendix F, are three normative specification
   appendices.  Other appendices include a number of informational parts
   discussing the changes, use cases, different considerations or
   motivations.
Section 6. General-Header Fields

General headers are headers that may be used in both requests and
   responses.  The general-headers are listed in Table 1:
                  +--------------------+----------------+
                  | Header Name        | Defined in     |
                  +--------------------+----------------+
                  | Accept-Ranges      | Section 18.5   |
                  |                    |                |
                  | Cache-Control      | Section 18.11  |
                  |                    |                |
                  | Connection         | Section 18.12  |
                  |                    |                |
                  | CSeq               | Section 18.20  |
                  |                    |                |
                  | Date               | Section 18.21  |
                  |                    |                |
                  | Media-Properties   | Section 18.29  |
                  |                    |                |
                  | Media-Range        | Section 18.30  |
                  |                    |                |
                  | Pipelined-Requests | Section 18.33  |
                  |                    |                |
                  | Proxy-Supported    | Section 18.38  |
                  |                    |                |
                  | Range              | Section 18.40  |
                  |                    |                |
                  | RTP-Info           | Section 18.45  |
                  |                    |                |
                  | Scale              | Section 18.46  |
                  |                    |                |
                  | Seek-Style         | Section 18.47  |
                  |                    |                |
                  | Server             | Section 18.48  |
                  |                    |                |
                  | Session            | Section 18.49  |
                  |                    |                |
                  | Speed              | Section 18.50  |
                  |                    |                |
                  | Supported          | Section 18.51  |
                  |                    |                |
                  | Timestamp          | Section 18.53  |
                  |                    |                |
                  | Transport          | Section 18.54  |
                  |                    |                |
                  | User-Agent         | Section 18.56  |
                  |                    |                |
                  | Via                | Section 18.57  |
                  +--------------------+----------------+
                 Table 1: The General Headers Used in RTSP
Section 12. Pipelining Support

Pipelining is a general method to improve performance of request/
   response protocols by allowing the requesting agent to have more than
   one request outstanding and to send them over the same persistent
   connection.  For RTSP, where the relative order of requests will
   matter, it is important to maintain the order of the requests.
   Because of this, the responding agent MUST process the incoming
   requests in their sending order.  The sending order can be determined
   by the CSeq header and its sequence number.  For TCP, the delivery
   order will be the same, between two agents, as the sending order.
   The processing of the request MUST also have been finished before
   processing the next request from the same agent.  The responses MUST
   be sent in the order the requests were processed.
   RTSP 2.0 has extended support for pipelining beyond the capabilities
   in RTSP 1.0.  As a major improvement, all requests involved in
   setting up and initiating media delivery can now be pipelined,
   indicated by the Pipelined-Request header (see Section 18.33).  This
   header allows a client to request that two or more requests be
   processed in the same RTSP session context that the first request
   creates.  In other words, a client can request that two or more media
   streams be set up and then played without needing to wait for a
   single response.  This speeds up the initial start-up time for an
   RTSP session by at least one RTT.
   If a pipelined request builds on the successful completion of one or
   more prior requests, the requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a PLAY request.  In case one of the SETUP requests fails
   unexpectedly, the PLAY request can still be successfully executed.
   However, the resulting presentation will not be as expected by the
   requesting client, as only a single media instead of two will be
   played.  In this case, the client can send a PAUSE request, correct
   the failing SETUP request, and then request it be played.
Section Appendix F. Text Format for Parameters

A resource of type "text/parameters" consists of either 1) a list of
   parameters (for a query) or 2) a list of parameters and associated
   values (for a response or setting of the parameter).  Each entry of
   the list is a single line of text.  Parameters are separated from
   values by a colon.  The parameter name MUST only use US-ASCII visible
   characters while the values are UTF-8 text strings.  The media type
   registration form is in Section 22.16.
   There is a potential interoperability issue for this format.  It was
   named in RFC 2326 but never defined, even if used in examples that
   hint at the syntax.  This format matches the purpose and its syntax
   supports the examples provided.  However, it goes further by allowing
   UTF-8 in the value part; thus, usage of UTF-8 strings may not be
   supported.  However, as individual parameters are not defined, the
   implementing application needs to have out-of-band agreement or using
   feature tag anyway to determine if the endpoint supports the
   parameters.
   The ABNF [RFC5234] grammar for "text/parameters" content is:
   file             = *((parameter / parameter-value) CRLF)
   parameter        = 1*visible-except-colon
   parameter-value  = parameter *WSP ":" value
   visible-except-colon = %x21-39 / %x3B-7E    ; VCHAR - ":"
   value            = *(TEXT-UTF8char / WSP)
   TEXT-UTF8char    = <as defined in Section 20.1>
   WSP              = <See RFC 5234> ; Space or HTAB
   VCHAR            = <See RFC 5234>
   CRLF             = <See RFC 5234>
Section Appendix G. Requirements for Unreliable Transport of RTSP

This appendix provides guidance for those who want to implement RTSP
   messages over unreliable transports as has been defined in RTSP 1.0
   [RFC2326].  RFC 2326 defined the "rtspu" URI scheme and provided some
   basic information for the transport of RTSP messages over UDP.  The
   information is being provided here as there has been at least one
   commercial implementation and compatibility with that should be
   maintained.
   The following points should be considered for an interoperable
   implementation:
   o  Requests shall be acknowledged by the receiver.  If there is no
      acknowledgement, the sender may resend the same message after a
      timeout of one round-trip time (RTT).  Any retransmissions due to
      lack of acknowledgement must carry the same sequence number as the
      original request.
   o  The RTT can be estimated as in TCP (RFC 6298) [RFC6298], with an
      initial round-trip value of 500 ms.  An implementation may cache
      the last RTT measurement as the initial value for future
      connections.
   o  The Timestamp header (Section 18.53) is used to avoid the
      retransmission ambiguity problem [Stevens98].
   o  The registered default port for RTSP over UDP for the server is
      554.
   o  RTSP messages can be carried over any lower-layer transport
      protocol that is 8-bit clean.
   o  RTSP messages are vulnerable to bit errors and should not be
      subjected to them.
   o  Source authentication, or at least validation that RTSP messages
      comes from the same entity becomes extremely important, as session
      hijacking may be substantially easier for RTSP message transport
      using an unreliable protocol like UDP than for TCP.
   There are two RTSP headers that are primarily intended for being used
   by the unreliable handling of RTSP messages and which will be
   maintained:
   o  CSeq: See Section 18.20.  It should be noted that the CSeq header
      is also required to match requests and responses independent
      whether a reliable or unreliable transport is used.
   o  Timestamp: See Section 18.53
Section Appendix H. Backwards-Compatibility Considerations

This section contains notes on issues about backwards compatibility
   with clients or servers being implemented according to RFC 2326
   [RFC2326].  Note that there exists no requirement to implement RTSP
   1.0; in fact, this document recommends against it as it is difficult
   to do in an interoperable way.
   A server implementing RTSP 2.0 MUST include an RTSP-Version of
   "RTSP/2.0" in all responses to requests containing RTSP-Version value
   of "RTSP/2.0".  If a server receives an RTSP 1.0 request, it MAY
   If the server chooses not to support RFC 2326, it MUST respond with a
   505 (RTSP Version Not Supported) status code.  A server MUST NOT
   respond to an RTSP 1.0 request with an RTSP 2.0 response.
   Clients implementing RTSP 2.0 MAY use an OPTIONS request with an
   RTSP-Version of "RTSP/2.0" to determine whether a server supports
   RTSP 2.0.  If the server responds with either an RTSP-Version of
   "RTSP/1.0" or a status code of 505 (RTSP Version Not Supported), the
   client will have to use RTSP 1.0 requests if it chooses to support
   RFC 2326.
H.1.  Play Request in Play State
   The behavior in the server when a Play is received in Play state has
   changed (Section 13.4).  In RFC 2326, the new PLAY request would be
   queued until the current Play completed.  Any new PLAY request now
   takes effect immediately replacing the previous request.
H.2.  Using Persistent Connections
   Some server implementations of RFC 2326 maintain a one-to-one
   relationship between a connection and an RTSP session.  Such
   implementations require clients to use a persistent connection to
   communicate with the server and when a client closes its connection,
   the server may remove the RTSP session.  This is worth noting if an
   RTSP 2.0 client also supporting 1.0 connects to a 1.0 server.