RFC Errata
RFC 4585, "Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/AVPF)", July 2006
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).