RFC Errata
Found 3 records.
Status: Rejected (3)
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
Publication Format(s) : TEXT
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
Publication Format(s) : TEXT
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.
Errata ID: 6862
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Chris Morgan
Date Reported: 2022-02-25
Rejected by: RFC Editor
Date Rejected: 2022-04-06
Section 3.6 says:
The syntax conforms to ISO 8601. The npt-sec notation is optimized for automatic generation, the ntp-hhmmss notation for consumption by human readers.
It should say:
The syntax conforms to ISO 8601. The npt-sec notation is optimized for automatic generation, the npt-hhmmss notation for consumption by human readers.
Notes:
A typo, ntp-hhmmss → npt-hhmmss.
--VERIFIER NOTES--
Already addressed in rfc7826