RFC Errata
Found 4 records.
Status: Verified (2)
RFC 4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006
Note: This RFC has been updated by RFC 5506, RFC 8108
Source of RFC: avt (rai)
Errata ID: 2853
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Ali Begen
Date Reported: 2011-07-05
Verifier Name: Robert Sparks
Date Verified: 2011-08-05
Section 4.2 says:
OLD: rtcp-fb-param = SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-param = [ SP "app" [SP byte-string] / SP token [SP byte-string] ] OLD: rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-ack-param = [ SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] ] OLD: rtcp-fb-nack-param = SP "pli" / SP "sli" / SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty NEW: rtcp-fb-nack-param = [ SP "pli" / SP "sli" / SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] ]
Notes:
During the AUTH48 of RFC 6285, we discovered a bug with the ABNF syntax in RFC 4585. The original ABNF in Section 4.2 (as noted above) is incorrect ("/ ;empty" is not a valid ABNF - RFC 5234 does not allow empty alternates).
The NEW text intends to fix it. There are 3 places where the same change should be applied (changes are identical).
Errata ID: 3313
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mo Zanaty
Date Reported: 2012-08-11
Verifier Name: Robert Sparks
Date Verified: 2012-11-26
Section 4.2 says:
rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] / ; empty
It should say:
rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string]
Notes:
RFC 4585 defines and allows generic NACK (with no further parameters) but not generic ACK (which always requires further parameters). Section 4.2 says:
...
Parameters MUST be provided to further distinguish different types
of positive acknowledgement feedback.
...
The feedback type "nack", without parameters, indicates use of the
Generic NACK feedback format as defined in Section 6.2.1.
...
The ABNF incorrectly allows nothing after "ack", implying that generic ACK is valid. Even the approved errata, which replaces the invalid empty alternate with optional [], still allows nothing after "ack". Note that recent interest in RTP congestion control (e.g. RMCAT BOF) may lead to defining a standard ACK.
Status: Rejected (2)
RFC 4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006
Note: This RFC has been updated by RFC 5506, RFC 8108
Source of RFC: avt (rai)
Errata ID: 51
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17
Errors (11)-(19) of 19
(11) [formatting issue] In Section 6, the text around the page break from page 31 to page 32 is not formatted properly. The RFC says: [...] audio and DTMF) or when codec changes occur, the payload type information may need to be conveyed explicitly as part of the FB message. This applies to all << page break >> payload-specific as well as application layer FB messages. It is up to the specification of an FB message to define how payload type information is transmitted. It should say: [...] audio and DTMF) or when codec changes occur, the payload type information may need to be conveyed explicitly as part of the FB message. This applies to all payload-specific as well as << page break >> application layer FB messages. It is up to the specification of an FB message to define how payload type information is transmitted. (12) [inconsistent text] Still in Section 6, the second paragraph on page 32 (immediately following the text quotation in item (11) above) says: vvv | This document defines two transport layer and three (video) payload- specific FB messages as well as a single container for application layer FB messages. Additional transport layer and payload-specific FB messages MAY be defined in other documents and MUST be registered through IANA (see Section 9, "IANA Considerations"). It should say: vvv | This document defines one transport layer and three (video) payload- specific FB messages as well as a single container for application layer FB messages. Additional transport layer and payload-specific FB messages MAY be defined in other documents and MUST be registered through IANA (see Section 9, "IANA Considerations"). Rationale: Cf. the third paragraph of Section 6, on page 31, and the subsequent pages, in particular page 34, where the second paragraph of Section 6.2 says: | A single general purpose transport layer FB message is defined in this document: Generic NACK. It is identified by means of the FMT parameter as follows: [...] (And so it does, per Section 6.2.1.) (13) [incomplete specification?] Within Section 6.1, the last paragraph on page 33 says: Each RTCP feedback packet MUST contain at least one FB message in the FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or not multiple FB messages MAY be compressed into a single FCI field. | If this is the case, they MUST be of the same type, i.e., same FMT. | If multiple types of feedback messages, i.e., several FMTs, need to be conveyed, then several RTCP FB messages MUST be generated and SHOULD be concatenated in the same compound RTCP packet. I strongly suspect -- and this is supported by the examples in the RFC -- that feedback packets to be combined MUST also have the same payload type (PT), not only agree in their FMT values. Otherwise, there would be no way to carry the different PT values in the FB message according to the format specified in Figure 3. Therefore, the RFC should say: Each RTCP feedback packet MUST contain at least one FB message in the FCI field. Sections 6.2 and 6.3 define for each FCI type, whether or not multiple FB messages MAY be compressed into a single FCI field. | If this is the case, they MUST be of the same type, i.e., same PT and | the same FMT. If multiple types of feedback messages, i.e., several | PTs and/or several FMTs, need to be conveyed, then several RTCP FB messages MUST be generated and SHOULD be concatenated in the same compound RTCP packet. (Authors, please supply alternative wording, if you desire.) Note: Perhaps, this issue arised because of the slightly differing semantics implied for the various usages of the term "FB message" in Section 6.1 -- (a) the whole RTCP FB message, and (b) a semantic entity carried in the FCI field of that RTCP message. Future updates to the RFC might try further clarifications of the text to avoid this subtle sematic overloading. (14) [missing article] The last paragraph of Section 6.3, at the bottom of page 35, says: The following subsections define the FCI formats for the payload- | specific FB messages, Section 6.4 defines FCI format for the application layer FB message. It should say: The following subsections define the FCI formats for the payload- | specific FB messages, Section 6.4 defines the FCI format for the application layer FB message. (15) [extraneous words] The second paragraph of Section 6.3.1.1, on page 36, says: Other RTP payload specifications such as RFC 2032 [6] already define | a feedback mechanism for some for certain codecs. An application supporting both schemes MUST use the feedback mechanism defined in this specification when sending feedback. For backward compatibility reasons, such an application SHOULD also be capable to receive and react to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format. It should say: Other RTP payload specifications such as RFC 2032 [6] already define | a feedback mechanism for certain codecs. An application supporting both schemes MUST use the feedback mechanism defined in this specification when sending feedback. For backward compatibility reasons, such an application SHOULD also be capable to receive and react to the feedback scheme defined in the respective RTP payload format, if this is required by that payload format. (16) [misleading wording] The first paragraph of Section 6.3.2.2, on page 37, says: vvvvv | The Slice Loss Indication uses one additional FCI field, the content of which is depicted in Figure 6. The length of the FB message MUST be set to 2+n, with n being the number of SLIs contained in the FCI field. To avoid the semantic overloading of the word "field", it should perhaps better say: vvvv | The Slice Loss Indication uses one additional FCI word, the content of which is depicted in Figure 6. The length of the FB message MUST be set to 2+n, with n being the number of SLIs contained in the FCI field. (17) [typo] The first paragraph of Section 6.3.3.1, on page 39, says: v [...]. As this reference picture is | temporally further away then usual, the resulting predictively coded picture will use more bits. It should say: v [...]. As this reference picture is | temporally further away than usual, the resulting predictively coded picture will use more bits. (18) [inappropriate wording] The first paragraph of Section 8, on page 42, says: RTP packets transporting information with the proposed payload format are subject to the security considerations discussed in the RTP specification [1] and in the RTP/AVP profile specification [2]. This profile does not specify any additional security services. The wording of the first sentence is inappropriate for this RFC. (It perhaps has been copied unchanged from an RFC with an RTP Payload specification.) RFC 4585 should say instead: | RTP packets transporting information as defined in various payload | formats supporting this profile are subject to the security considerations discussed in the RTP specification [1] and in the RTP/AVP profile specification [2]. This profile does not specify any additional security services. (19) [redundant Ref.] The Normative Reference [7] (in Section 11.1, on page 48) and the Informative Reference [20] (in Section 11.2, on page 49) both point to RFC 3448. ([7] and [20] are referred to once each in the RFC text.) This is unusual and unexpected. Only one pointer to RFC 3448 should have been specified. Authors, please check.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.
We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).
Errata ID: 768
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-17
Rejected by: Joerg Ott
Date Rejected: 2006-08-17
Errors (1)-(10) of 19
(1) Section 1.1 of RFC 4585, on mid-page 4, says: Feedback (FB) message: An RTCP message as defined in this document is used to convey information about events observed at a receiver -- in addition to long-term receiver status information that is carried in RTCP receiver reports (RRs) -- back to the sender of the media stream. | For the sake of clarity, feedback message is referred to as FB | message throughout this document. I do not see how and why using the abbreviation might have improved *clarity* of the text; apparently, it has been used for *brevity* . Therefore, the two tagged lines should better say: | For the sake of brevity, feedback message is referred to as FB | message throughout this document. Similarly, at the bottom of page 4, where the RFC says: Feedback (FB) threshold: The FB threshold indicates the transition between Immediate Feedback and Early RTCP mode. [...] [...] to application designers and is not used in any calculations. For | the sake of clarity, the term feedback threshold is referred to as FB threshold throughout this document. The last 3 lines should better say: to application designers and is not used in any calculations. For | the sake of brevity, the term feedback threshold is referred to as FB threshold throughout this document. (2) The first bulleted item in Section 3.1, on page 7, says: vvvvvvvvvvvvv | o Status reports are contained in sender report (SR)/received report (RR) packets and are transmitted at regular intervals as part of compound RTCP packets (which also include source description (SDES) and possibly other messages); these status reports provide an overall indication for the recent reception quality of a media stream. For *clarity*, it perhaps should better say -- not binding together the words intended to being separated by the slash marking the alternative: vvv | o Status reports are contained in sender report (SR) / received report (RR) packets and are transmitted at regular intervals as part of compound RTCP packets (which also include source description (SDES) and possibly other messages); these status reports provide an overall indication for the recent reception quality of a media stream. (3) [missing article] In Section 3.4, on mid-page 11, RFC 4585 says: j) Let T_fd be the actual (randomized) delay for the transmission of FB message in response to an event at time t0. It should say: j) Let T_fd be the actual (randomized) delay for the transmission of | a FB message in response to an event at time t0. ^^ (4) [inappropriate wording] The algorithm in Section 3.5.2, at the bottom of page 16, contains the sub-step: 4b) If allow_early == TRUE, then R MUST schedule an Early RTCP packet for te = t0 + RND * T_dither_max with RND being a | pseudo random function evenly distributed between 0 and 1. ^^^^^^^^ This wording is inappropriate. RND is not a *function* (that's code!), but a *number*, the function *value*. Therefore, the RFC should say: 4b) If allow_early == TRUE, then R MUST schedule an Early RTCP packet for te = t0 + RND * T_dither_max with RND being a | pseudo random number evenly distributed between 0 and 1. ^^^^^^ (5) [inappropriate wording] The algorithm in Section 3.5.3, at the top of page 19, says: 2. Otherwise, a temporary value T_rr_current_interval is calculated as follows: T_rr_current_interval = RND*T_rr_interval | with RND being a pseudo random function evenly distributed between 0.5 and 1.5. This dithered value is used to determine one of the following alternatives: Similar to item (4) above, the RFC should say instead: 2. Otherwise, a temporary value T_rr_current_interval is calculated as follows: T_rr_current_interval = RND*T_rr_interval | with RND being a pseudo random number evenly distributed between 0.5 and 1.5. This dithered value is used to determine one of the following alternatives: (6) [typo / dup. wording] Section 3.6.2 of RFC 4585, on mid-page 21, says: Example: If a 256-kbit/s video with 30 fps is transmitted through a network with an MTU size of some 1,500 bytes, then, in most cases, | each frame would fit in into one packet leading to a packet rate of 30 packets per second. [...] It should say: Example: If a 256-kbit/s video with 30 fps is transmitted through a network with an MTU size of some 1,500 bytes, then, in most cases, | each frame would fit into one packet leading to a packet rate of 30 packets per second. [...] (7) [wrong ref. tag] On mid-page 23, Section 4.1 of RFC 4585 says: vvv | The AV profile defined in [4] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF". There apparently is a confusion of the ref. tags used. The RFC should say: vvv | The AV profile defined in [2] is referred to as "AVP" in the context of, e.g., the Session Description Protocol (SDP) [3]. The profile specified in this document is referred to as "AVPF". (8) [missing article] In Section 4.2, near the top of page 25, the ABNF production: rtcp-fb-pt = "*" ; wildcard: applies to all formats | / fmt ; as defined in SDP spec should better say, improving the ABNF comment text: rtcp-fb-pt = "*" ; wildcard: applies to all formats | / fmt ; as defined in the SDP spec ^^^^^ (9) [inconsistent specification] In Section 4.2, the ABNF on page 25 contains the following productions: rtcp-fb-val = "ack" rtcp-fb-ack-param / [...] and rtcp-fb-ack-param = SP "rpsi" / SP "app" [SP byte-string] / SP token [SP byte-string] | / ; empty This means that the feedback type "ack" *MAY* have parameters. Contrary to that, below the ABNF, the RFC explains: Feedback type "ack": This feedback type indicates that positive acknowledgements for feedback are supported. The feedback type "ack" MUST only be used if the media session is allowed to operate in ACK mode as defined in Section 3.6.1. | Parameters MUST be provided to further distinguish different types | of positive acknowledgement feedback. [...] The *MUST* in the tagged lines contradicts the ABNF. Authors, please resolve the issue: Either have the ABNF changed by omission of the tagged line above, | / ; empty or change the tagged explanation lines to say: | Parameters MAY be provided to further distinguish different types | of positive acknowledgement feedback. (10) [incomplete specification, and an extraneous word] At the bottom of page 26, Section 4.2 of RFC 4585 says: Other feedback types <rtcp-fb-id>: Other documents MAY define additional types of feedback; to keep the grammar extensible for those cases, the rtcp-fb-id is | introduced as a placeholder. A new feedback scheme name MUST to be unique (and thus MUST be registered with IANA). Along with a | new name, its semantics, packet formats (if necessary), and rules for its operation MUST be specified. It should say: Other feedback types <rtcp-fb-id>: Other documents MAY define additional types of feedback; to keep the grammar extensible for those cases, the rtcp-fb-id is | introduced as a placeholder. A new feedback scheme name MUST be unique (and thus MUST be registered with IANA). Along with a new | new name, its semantics, possible parameters, packet formats (if necessary), and rules for its operation MUST be specified. Rationale: a) "MUST to be unique" should be "MUST be unique". b) Syntax and semantics of parameters (if any) obviously MUST be specified as well. The RFC text in the IANA Considerations (Section 9) already reflects this requirement. For completeness and clarity, it should be stated here as well. I have proposed minimal additional wording -- you might choose alternative words.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the review. I have only quickly skimmed your comments
and there does not seem to be anything serious.
We will be happy to archive these and migt consider them if
we do a revision of the RFC. But an errata document would
only make sense if there is something seriously hindering
interoperability. I have not seen anything falling into this
category (well, and there are implementations out there from
the spec).