RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 2 records.

Status: Rejected (2)

RFC 2326, "Real Time Streaming Protocol (RTSP)", April 1998

Note: This RFC has been obsoleted by RFC 7826

Source of RFC: mmusic (rai)

Errata ID: 4199

Status: Rejected
Type: Technical

Reported By: Julius Friedman
Date Reported: 2014-12-11
Rejected by: Ben Campbell
Date Rejected: 2015-06-05

Section 4 says:

4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

It should say:


4 RTSP Message

   RTSP is a text-based protocol and uses the ISO 10646 character set in
   UTF-8 encoding (RFC 2279 [21]). Lines are terminated by CRLF, but
   receivers should be prepared to also interpret CR and LF by
   themselves as line terminators.

     Text-based protocols make it easier to add optional parameters in a
     self-describing manner. Since the number of parameters and the
     frequency of commands is low, processing efficiency is not a
     concern. Text-based protocols, if done carefully, also allow easy
     implementation of research prototypes in scripting languages such
     as Tcl, Visual Basic and Perl.

     The 10646 character set avoids tricky character set switching, but
     is invisible to the application as long as US-ASCII is being used.
     This is also the encoding used for RTCP. ISO 8859-1 translates
     directly into Unicode with a high-order octet of zero. ISO 8859-1
     characters with the most-significant bit set are represented as
     1100001x 10xxxxxx. (See RFC 2279 [21])

   RTSP messages can be carried over any lower-layer transport protocol
   that is 8-bit clean.

   Requests contain methods, the object the method is operating upon and
   parameters to further describe the method. Methods are idempotent,
   unless otherwise noted. Methods are also designed to require little
   or no state maintenance at the media server.

*Please note the hexadecimal octet 0x36 should not be included in any 
part of a RTSP message, if present it should be replaced with binary 
escaped sequence as defined in: <consensus>*.

Notes:

Section [15.1 Base Syntax] makes the following definitions:
..
safe = "\$" | "-" | "_" | "." | "+"
..
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "="
extra = "!" | "*" | "$'$" | "(" | ")" | ","
unreserved = alpha | digit | safe | extra
xchar = unreserved | reserved | escape

However it doesn't explicitly state the association of "$" [hexadecimal 0x24]

Section [10.12 Embedded (Interleaved) Binary Data] specified a mechanism of transferring RTSP messages over a TCP connection with a application layer header consisting of the hexadecimal octet 0x24; followed by a single octet channel identifier and the RFC4571 length specifier of the frame.

Due to the fact 0x24 violates section 4's requirements based on the fact it cannot be masked with the octet (AND 0xc3) to ensure it is a valid character I am filing this errata.

The chosen octet may also be present, specifically in the types of RTSP messages which are interleaved during playback such as ANNOUNCE. E.g. 0x24 could be a part of the configuration specifying the bits per pixel or audio bit depth as part of the SDP inter alia.

In such cases the underlying parser would interpret this octet as the start of the defined application header and cause framing errors which could cause data loss as allow for buffer overflow attacks of carefully crafted binary data.

There are also definitions which need to be made in the stadard for what to do when less then the amount of bytes indicated by the application layer frame header are or are not present. (e.g. more or less bytes are required then are present during reception of the given the [$CXX] application header sequence).

It is based on these considerations among others that I recommend that "$" [hexadecimal octet 0x24] be added to the reserved list and if necessary an escaping mechanism be defined where it is replaced with an escaped sequence which is agreed upon after consensus.

Due to the fact that drafts also specify that RTSP can be extended with any type of message so long as the data is not "$" the first character it is ambiguous may also appear elsewhere in the status line.

There are also issues with the ambiguous definition of pdu fragmentation defined in the latest draft, e.g. the mechanism defined as possibly required when pdu's larger then 65535 bytes are used however it specified no way to convey how this occurs or why.

The same can also be said for "sink" and "source" however I will address those definitions et al when appropriate.

Thank you for your time!

The review noted the following:

"The reason is that is is technical change that can cause compatibility issues, and
further does not resolve the issue as it is missing the required
escaping definitions (another technical change). In addition we know
that RFC 2326 is quite buggy and attempting to fix it with Errata does
not work."

MMUSIC is considering whether this should be fixed in RTSP 2.0.
--VERIFIER NOTES--
The reviewer noted the following:

"The reason is that is is technical change that can cause compatibility issues, and
further does not resolve the issue as it is missing the required
escaping definitions (another technical change). In addition we know
that RFC 2326 is quite buggy and attempting to fix it with Errata does
not work."

MMUSIC is considering whether this should be fixed in RTSP 2.0.

Errata ID: 5079

Status: Rejected
Type: Technical

Reported By: Vadim Zhukov
Date Reported: 2017-08-08
Rejected by: Ben Campbell
Date Rejected: 2017-09-13

Section 10.8 says:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 15

           packets_received
           jitter

It should say:

     S->C: GET_PARAMETER rtsp://example.com/fizzle/foo RTSP/1.0
           CSeq: 431
           Content-Type: text/parameters
           Session: 12345678
           Content-Length: 24

           packets_received
           jitter

Notes:

The Content-Length value is wrong, it should be either 24 (as proposed) or 26, depending on end-of-line marker used for message content.
--VERIFIER NOTES--
RFC 2326 has been obsoleted by RFC 7826. The similar examples in RFC 7826 appear to have correct content-length field values.

Report New Errata