RFC Errata
Found 1 record.
Status: Held for Document Update (1)
RFC 4587, "RTP Payload Format for H.261 Video Streams", August 2006
Source of RFC: avt (rai)
Errata ID: 49
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-10-31
Held for Document Update by: Robert Sparks
(1) "Updates" relationship missing in RFC header & RFC index
In the Introduction (3rd paragraph on page 3) the RFC says:
This document obsoletes RFC 2032 and updates the "video/h261" media
type that was registered in RFC 3555.
Similar wording is in Section 6.1 (see below).
Therefore, I expect that the RFC heading should have been amended
by a "Updates: 3555" line, and that this relationship be visible in
the RFC index.
(2) Misleading packetization specification
On page 4, in the first paragraph of Section 3.2, RFC 4587 says:
[..]. The 512-bit frames are then interlaced with an audio stream
and transmitted over px 64 kbps circuits according to specification
H.221 [H221].
^^^^^^^^^^
For clarity, it should say:
[..]. The 512-bit frames are then interlaced with an audio stream
and transmitted over p x 64 kbps circuits according to specification
H.221 [H221].
^^^^^^^^^^^
(and/or replace the 'x' by an asterisk, '*' !)
(2')
The same issue recurs on page 15, in the first item of Section 11.1,
the Normative Reference, [H261] .
(3) Improper frequency specification
According to the applicable ISO standards on Measures and Weights,
there is never a special sign to be written between the numeric value
and the physical unit of any dimensioned physical value.
(Preferrably, there should not even be any white space between.)
Therefore, in Section 4.1 of RFC 4587, at the bottom of page 5,
where the RFC says:
[...]. For H.261 video streams, the RTP timestamp is based on
| a 90-kHz clock. This clock rate is a multiple of the natural H.261
frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]
it in fact should say:
[...]. For H.261 video streams, the RTP timestamp is based on
| a 90 kHz clock. This clock rate is a multiple of the natural H.261
frame rate (i.e., 30000/1001 or approximately 29.97 Hz). [...]
(Rigorous application of the above principles, taking 'bit' as a unit
specification, would also forbid data amount spellings like "512-bit"
in item (2) above!)
(4) misaligned 'ruler lines' above data format diagrams
According to legacy and current RFC author guidelines, the ruler lines
above the two data format diagrams on page 6 (within Section 4.1):
| 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
should be indented as follows:
| 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(5) improper wording (2 instances)
Near the top of page 7, the explanations for the (I) and (V) bits
both contain the sentence:
vvvvvvv
[...]. The meaning of this bit should not be changed during the
course of the RTP session.
This is abuse of language.
The *meaning* of the bit -- i.e., the bit *values* -- is given in the
text preceding the quoted sentence, and thus intrinsically cannot be
changed during the course of the RTP session.
What in fact should not be changed during the RTP session is the
*value* of these bits!
Therefore, the RFC should say (in both places):
vvvvv
| [...]. The value of this bit should not be changed during the
course of the RTP session.
(6) typo
In Section 5, on page 9, the last sentence of the bullet (3) says:
[...]. This mode is particularly
efficient in point-to-point connection or when the number of
decoders is low.
It should say:
[...]. This mode is particularly
| efficient in a point-to-point connection or when the number of
decoders is low.
or:
[...]. This mode is particularly
| efficient in point-to-point connections or when the number of
decoders is low.
(7) misleading section headlines
In the RFC text, Section
6. IANA Considerations
contains the following sub-sections:
6.1. Media Type Registrations
6.1.1. Registration of MIME Media Type video/H261
6.2. SDP Parameters
6.2.1. Usage with the SDP Offer Answer Model
Only Section 6.1[.1] contains information addressed to the IANA.
Therefore, for clarity (and to avoid undue burden for the IANA),
the first two of the headlines quoted above should effectively be
exchanged. And, there is only one (1) registration!
Hence, singular should be used.
Furthermore, the text of Section 6.1 contains improper wording
and has no trailing fullstop (dot) character:
| This section describes the media types and names associated with this
| payload format. The section updates the previous registered version
in RFC 3555 [RFC3555]. This registration uses the template defined
| in RFC 4288 [RFC4288]
Thus, the headline
6. IANA Considerations
should be corrected to say, e.g.:
6. Media Type video/H261
and
6.1. Media Type Registrations
[... paragraph quoted above ... ]
should be replaced by:
6.1 IANA Considerations
| This section describes the media type and parameters associated with
| this payload format. It updates the previous registered version in
RFC 3555 [RFC3555]. This registration uses the template defined
| in RFC 4288 [RFC4288].
(8) typo
The last sentence (of the last bullet) of Section 6.2, on page 12,
says:
[...]. These parameters are
expressed as a MIME media type string, in the form of as a
semicolon-separated list of parameters
^^^^
It should say:
[...]. These parameters are
| expressed as a MIME media type string, in the form of a
semicolon-separated list of parameters
(9) typo and misleading wording in Section 6.2.1
The first paragraph of Section 6.2.1, on page 12, says:
When H.261 is offered over RTP using SDP in an Offer/Answer model
[RFC3264] the following considerations are necessary.
This could easily be misunderstood as talking about an
'SDP offer over RTP'.
The RFC should say instead (exchanging two pairs of words):
When H.261 over RTP is offered using SDP in an Offer/Answer model
[RFC3264] the following considerations are necessary.
Subsequently, the paragraph with the headline "Picture sizes and MPI",
Supported picture sizes and their corresponding minimum picture
interval (MPI) information for H.261 can be combined. All picture
sizes may be advertised to the other party, or only a subset of it.
Using the recvonly or sendrev direction attribute, a terminal SHOULD
announce those picture sizes (with their MPIs) that it is willing to
receive. For example, CIF=2 means that receiver can receive a CIF
picture and that the frame rate SHALL be less then 15 frames per
second.
Should be corrected and clarified to say:
Supported picture sizes and their corresponding minimum picture
interval (MPI) information for H.261 can be combined. All picture
sizes may be advertised to the other party, or only a subset of it.
| Using the recvonly or sendrec direction attribute, a terminal SHOULD
announce those picture sizes (with their MPIs) that it is willing to
| receive. For example, CIF=2 means that the SDP sender can receive a
CIF picture and that the frame rate SHALL be less then 15 frames per
second.
(There is no 'sendrev' direction attribute, and it is important to
explicitely differentiate between senders and receivers of SDP and
media, respectively!)
Finally, the second paragraph on page 13,
An example of media representation in SDP is as follows CIF at 15
frames per second, QCIF at 30 frames per second and annex D
should better say:
| An example of media representation in SDP is as follows:
CIF at 15 frames per second, QCIF at 30 frames per second and annex D
or, perhaps even better:
| An example of media representation in SDP, for CIF at 15 frames per
| second, QCIF at 30 frames per second and annex D, is as follows:
Notes:
from pending