RFC Errata
Found 2 records.
Status: Rejected (2)
RFC 4588, "RTP Retransmission Payload Format", July 2006
Source of RFC: avt (rai)
Errata ID: 48
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Section 8.1 says:
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt". The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
It should say:
The following MIME subtype name and parameters are introduced in this document: "rtx", "rtx-time", and "apt". The binding used for the retransmission stream to the payload type number is indicated by an rtpmap attribute. The MIME subtype name used in the binding is "rtx". The MIME type of the retransmission stream MUST be the same as the MIME type of the original stream. The "apt" (associated payload type) parameter MUST be used to map the retransmission payload type to the associated original stream payload type. If multiple original payload types are used, then multiple "apt" parameters MUST be included to map each original payload type to a different retransmission payload type.
Notes:
This text only addresses the use of the media *sub*-type. Apparently,
it is implied that the media *type* of the associated streams match,
but I could not find a statement to this end in the RFC.
(In accordance with the language of RFC 4588, but contrary to BCP 13,
RFC 4288, I have again used the traditional wording "MIME type" here
instead of the currently recommended "media type".)
from pending
--VERIFIER COMMENT--
Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:
"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: 759
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-14
Rejected by: Jose Rey
Date Rejected: 2006-08-29
(1) [missing article] Within Section 4 of RFC 4588, the second paragraph on page 8 says: [...]. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done | with Session Description Protocol (SDP). It should say: [...]. See Section 8.1 for the specification of how the mapping between original and retransmission payload types is done | with the Session Description Protocol (SDP). ^^^^^ (2) [improper wording] The 4th paragraph of Section 6.3, on page 12, says: [...]. In such cases, an appropriate "reorder delay" algorithm may not actually be timer based, but packet based. For | example, if n number of packets are received after a gap is detected, then it may be assumed that the packet was truly lost rather than out of order. This may turn out to be far easier to code on some platforms as a very short fixed FIFO packet buffer as opposed to the timer-based mechanism. It should say: [...]. In such cases, an appropriate "reorder delay" algorithm may not actually be timer based, but packet based. For | example, if n packets are received after a gap is detected, then it may be assumed that the packet was truly lost rather than out of order. This may turn out to be far easier to code on some platforms as a very short fixed FIFO packet buffer as opposed to the timer- based mechanism. (Alternatively, use "if a number n of packets ..." instead of the offending "if n number of packets ..." ) (3) [word omission] In the first paragraph of Section 6.4, on page 13, RFC 4588 says: [...] v | Sending NACKs only in regular RTCP compound decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. Implementers should consider the possible implications of this fact for the application being used. It should say: [...] vvvvvvvvv | Sending NACKs only in regular RTCP compound packets decreases the maximum delay between detecting an original packet loss and being able to send a NACK for that packet. Implementers should consider the possible implications of this fact for the application being used. (4) [[posted separately.]] (5) [word omission] Later on in Section 8.1, on mid-page 15, the RFC says: v | The syntax is as follows: a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val> It should say: vvvvv | The SDP syntax is as follows: a=fmtp:<number> apt=<apt-value>;rtx-time=<rtx-time-val> (There also is a syntax for these parameters when written in a full MIME media type specification; this is not presented in the RFC, but it must be distinguished from the SDP syntax presented!) (6) [excessive text] The final paragraph of Section 8.6, on mid-page 20, says: In the following sections, some example SDP descriptions are | presented. In some of these examples, long lines are folded to meet | the column width constraints of this document; the backslash ("\") at | the end of a line and the carriage return that follows it should be | ignored. It would suffice to say: In the following sections, some example SDP descriptions are | presented. Rationale: As will be shown below, in the examples given in Section 8.7, there in fact is no need to perform this artificial line folding. (7) [simplification for improved clarity] The artificial line folding in the examples in Section 8.7 can be avoided without change in the indentation, while still conforming with the line length limitations: a) In the upper half of page 21, the lines, a=fmtp:98 profile-level-id=8;config=01010000012000884006682C209\ 0A21F should read: a=fmtp:98 profile-level-id=8;config=01010000012000884006682C2090A21F b) In the lower half of page 21, the lines, a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 0A21F should read: a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F c) In the upper half of page 22, the lines, a=fmtp:96 profile-level-id=8;config=01010000012000884006682C209\ 0A21F should read: a=fmtp:96 profile-level-id=8;config=01010000012000884006682C2090A21F (8) [clarification] On mid-page 21, the text in Section 8.7 says: A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" line, the grouping is then obvious and FID semantics MAY be omitted in this special case only. It should better say: A special case of the SDP description is a description that contains only one original session "m" line and one retransmission session "m" | line, the grouping is then obvious and lines with grouping syntax (FID semantics) MAY be omitted in this special case only. Rationale: It is impossible to only omit *semantics*. Certain *lines* are omitted there -- the lines with grouping syntax (and FID semantics). Alternatively, "(FID semantics)" might be omitted entirely from the changed text, as well. (9) [word omission -- clarification] The first paragraph of Section 10.2, on page 25, says: This section shows how to combine retransmissions with layered encoding in multicast sessions. Note that the retransmission framework is offered only for small multicast applications. Refer to RFC 2887 [10] for a discussion of the problems of NACK implosion, severe congestion caused by feedback traffic, in large-group reliable multicast applications. It should better say: This section shows how to combine retransmissions with layered encoding in multicast sessions. Note that the retransmission framework is offered only for small multicast applications. Refer to | RFC 2887 [10] for a discussion of the problems of NACK implosion, and severe congestion caused by feedback traffic, in large-group reliable multicast applications. ^^^ (10) [word omission] In the first paragraph on page 27, text within Section 13 says: [...]. Refer to Section 9.1 of the Secure Real-Time Transport Protocol (SRTP) [12] for a | discussion the implications of two-time pads and how to avoid them. ^ It should say: vvvvvvvvvvvvvvv [...]. Refer to Section 9.1 | of the Secure Real-Time Transport Protocol (SRTP) specification [12] | for a discussion of the implications of two-time pads and how to avoid them. ^^^^ (11) [inconsistency] In the fourth bullet on page 29, Appendix A.1 says: * avg-rtcp-size is approximated by 120 bytes. This is a rounded-up average of 2 SRs, one for each SSRC, containing 40/8/28/32 bytes for IPv6/UDP/SR/SDES with CNAME, thus making 105 bytes each; and a RR with 40/8/64/32 bytes for IPv6/UDP/2*RR/SDES, making 157 bytes. [...] I cannot follow these computations: 40+8+28+32 = 105 ??? and 40+8+64+32 = 157 ??? What is wrong there? Authors, please correct ! BTW: What follows in the text essentially does not depend on the exact figures, the rough order of magnitude is all that is needed. But the presentation should be self-consistent. (12) [improvement of wording] In the 6th bullet of Appendix A.1, the text on page 29/30 says: [...]. This means that if a packet is requested for retransmission a maximum of 2 times, the corresponding generic NACK report block requesting that particular packet is sent in two << page break >> | consecutive RTCP compounds; likewise, if it is requested for retransmission 10 times, then the generic NACK is sent 10 times. [...] It should say: [...]. This means that if a packet is requested for retransmission a maximum of 2 times, the corresponding generic NACK report block requesting that particular packet is sent in two << page break >> | consecutive RTCP compound packets; likewise, if it is requested for retransmission 10 times, then the generic NACK is sent 10 times. [...] (13) [missing argument / clarification] On page 31, Appendix A.2 says: vv | To find an estimate of the buffering time, T(), that a streaming server shall use in order to enable a given number of retransmissions for each packet, N. [...] It should say: vvv | To find an estimate of the buffering time, T(N), that a streaming server shall use in order to enable a given number of retransmissions for each packet, N. [...] (14) [fractional sign] Within the tables in Appendix A.4, on pages 32 and 33, the RFC text uses the comma (",") as the fractional sign (central european style). In IETF documents, the decimal point (".") should be used instead. Authors, Please comment. Items (4) / (11) need agreement / text correction from you. Items (6) + (7) might be considered non-esssential. All other items seem to be straightforward and suitable for inclusion in an Errata Note.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for your comments. However, I don't consider them worth of correction. Most are just editorial nits, some of which are even wrong. So, for the time being as Joerg said:
"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)."