RFC 5109, "RTP Payload Format for Generic Forward Error Correction", December 2007

Errata ID: 1226
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Adam Li
Date Reported: 2008-01-03
Rejected by: Robert Sparks
Date Rejected: 2010-10-28

Section 9.1 says:

In Step 13,

      13. Take the next 16 bits of the recovery bit string.  Whatever
          unsigned integer this represents (assuming network-order),
          take that many bytes from the recovery bit string and append
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          them to the new packet.  This represents the CSRC list,
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
          extension, payload, and the padding of the RTP payload.

It should say:

      13. Take the next 16 bits of the recovery bit string.  Whatever
          unsigned integer this represents (assuming network-order),
          it represents the cumulative length of the CSRC list,
          ^^            ^^^^^^^^^^^^^^^^^^^^^^^^
          extension, payload, and the padding of the RTP payload
          of the packet to be recovered.
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Notes:

--VERIFIER NOTES--
From Peter Musgrave's review:
Editorial: rephrases a step in the instructions for RTP header reconstruction
Action: Rejected (In my opinion the new text is not significantly clearer and the use of the word cumulative is a bit confusing).

Report New Errata