RFC Errata
Found 9 records.
Status: Held for Document Update (9)
RFC 5215, "RTP Payload Format for Vorbis Encoded Audio", August 2008
Source of RFC: avt (rai)
Errata ID: 1659
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Cullen Jennings
Section 2.2, pg.6 says:
This field specifies the kind of Vorbis data stored in this RTP
packet. There are currently three different types of Vorbis
payloads. Each packet MUST contain only a single type of Vorbis
packet (e.g., you must not aggregate configuration and comment
packets in the same RTP payload).
0 = Raw Vorbis payload
1 = Vorbis Packed Configuration payload
2 = Legacy Vorbis Comment payload
3 = Reserved
It should say:
This field specifies the kind of Vorbis data stored in this RTP
| payload. There are currently three different types of Vorbis
| packets. Each RTP payload MUST contain only a single type of Vorbis
packet (e.g., you must not aggregate configuration and comment
packets in the same RTP payload).
| 0 = Raw Vorbis packet
| 1 = Vorbis Packed Configuration packet
| 2 = Legacy Vorbis Comment packet
3 = Reserved
Notes:
Rationale:
The RFC is about an RTP *payload* format, and, according to
section 1 of the RFC, deals with Vorbis *packets* -- to be
encapsulated in the RTP payload.
Section 2.2 explains the RTP Payload Header vor Vorbis. Thus,
the use of "payload" and "packet" in the Original Text does
not match these definitions and hence might well be confusing.
The Corrected Text aims at placing the proper terms there.
Errata ID: 1661
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 3.1.1, pg.11 says:
The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 because the packet bears the full Packed configuration. The | number of the packet is set to 1. ^^^^^^^^^^^^^^^^^^^^
It should say:
The Ident field is set with the value that will be used by the Raw Payload Packets to address this Configuration. The Fragment type is set to 0 because the packet bears the full Packed configuration. The | number of packets is set to 1. ^^^^^^^^^^^^^^^^^
Notes:
Rationale:
According to Section 2.2 of the RFC, the last field in the
Payload Header is "number of packets", not "number of the packet"
(which might be misunderstood as some kind of sequence number).
It seems to be prudent to use the precise field name.
Errata ID: 1660
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 3.1, pg.9 says:
The Packed Configuration (Section 3.1.1) Payload is sent in-band with the packet type bits set to match the Vorbis Data Type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission | of [RFC4588] the configuration headers. [...] ^^^^^^^^^^^^
It should say:
The Packed Configuration (Section 3.1.1) Payload is sent in-band with the packet type bits set to match the Vorbis Data Type. Clients MUST be capable of dealing with fragmentation and periodic re-transmission | [RFC4588] of the configuration headers. [...] ^^^^^^^^^^^^
Notes:
Rationale: cunfusing word twister!
Errata ID: 1662
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 5.1,1st para says:
Here is an example of a fragmented Vorbis packet split over three RTP
| payloads. Each of them contains the standard RTP headers as well as
| the 4-octet Vorbis headers.
^ ^
It should say:
Here is an example of a fragmented Vorbis packet split over three RTP | payloads. Each of them contains the standard RTP header as well as | the 4-octet Vorbis header.
Notes:
Rationale:
Confusing use of plural: Each RTP packet contains a single
standard RTP header and a single 4-octet Vorbis header.
Errata ID: 1663
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 5.2,2nd para says:
| Loss of any of the Configuration fragment will result in the loss of the full Configuration packet with the result detailed in the Loss of | Configuration Headers (Section 3.3) section.
It should say:
| Loss of any fragment of the Configuration packet will result in the loss of the full Configuration packet with the result detailed in the | Loss of Configuration Headers section (Section 3.3).
Notes:
Rationale: Clarification / improved language
Errata ID: 1664
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 6/6.* titles says:
Section 6 is structured as follows: |6. IANA Considerations | ... <IANA registration of media type audio/vorbis> ... |6.1. Packed Headers IANA Considerations | | The following IANA considerations refers to the split configuration | Packed Headers (Section 3.2.1) used within RFC 5215. ... <IANA registration of media type audio/vorbis-config> ...
It should say:
Section 6 is structured as follows: |6. IANA Considerations | | The following subsections contain the IANA registrations (in | accordance with RFC 4855 using the registration template of | RFC 4288) of the media types for the basic Vorbis payload format | and the Packed Headers payload format (Section 3.2.1). | |6.1. IANA registration of media type audio/vorbis | ... <IANA registration of media type audio/vorbis> ... |6.2. IANA registration of media type audio/vorbis-config | ... <IANA registration of media type audio/vorbis-config> ...
Notes:
Rationale:
The section structure and titles do not properly match the contents
of the whole section and should be corrected for clarity.
Because the applicable RFC 4288 and RFC 4855 have no entries in the
References section of this RFC, they are quoted only informally.
In the Correcte Text, the explanatory text has been moved to up to
6. and expanded accordingly to describe the whole section content.
Errata ID: 1665
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 7.1, p.21/21 says:
The information carried in the Media Type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP
| is used to specify sessions, the mapping are as follows:
[...]
| o The mandated parameters "configuration" MUST be included in the
SDP "a=fmtp" attribute.
[...]
It should say:
The information carried in the Media Type specification has a
specific mapping to fields in the Session Description Protocol (SDP)
[RFC4566], which is commonly used to describe RTP sessions. When SDP
| is used to specify sessions, the mapping is as follows:
[...]
| o The mandated parameter "configuration" MUST be included in the
SDP "a=fmtp" attribute.
[...]
Notes:
Rationale:
Grammar; there is only a single mapping (first paragraph of the section)
and only a single mandatory parameter (last bullet (of 5)).
Errata ID: 1666
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 7.1.1 says:
7.1.1. SDP Example The following example shows a basic SDP single stream. The first | configuration packet is inside the SDP; other configurations could be | fetched at any time from the URIs provided. The following base64 | [RFC4648] configuration string is folded in this example due to RFC line length limitations. | c=IN IP4 192.0.2.1 | | m=audio RTP/AVP 98 | | a=rtpmap:98 vorbis/44100/2 | | a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; Note that the payload format (encoding) names are commonly shown in | uppercase. Media Type subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, | parameter names are case-insensitive both in Media Type types and in the default mapping to the SDP a=fmtp attribute. The a=fmtp line is | a single line, even if it is shown as multiple lines in this document | for clarity.
It should say:
7.1.1. SDP Example The following example shows a basic SDP single stream. The first | configuration packet is inside the SDP. The following base64 | [RFC4648] configuration string is truncated in this example due to RFC line length limitations. | c=IN IP4 192.0.2.1 | m=audio RTP/AVP 98 | a=rtpmap:98 vorbis/44100/2 | a=fmtp:98 configuration=AAAAAZ2f4g9NAh4aAXZvcmJpcwA...; Note that the payload format (encoding) names are commonly shown in | uppercase. Media Types and Subtypes are commonly shown in lowercase. These names are case-insensitive in both places. Similarly, | parameter names are case-insensitive both in Media Types and in the default mapping to the SDP a=fmtp attribute. The a=fmtp line is | shown incompletely in this document for clarity.
Notes:
Rationale:
a) There is no URI provided; the corresponding remark is misleading
and therefore has been deleted in the Corrected Text.
b) The example does not contain folded lines; one line is shown only
partially -- for brevity this is denoted as truncation, and the
confusing remarks regarding line folding have been deleted in the
Corrected Text.
c) Spurious blank lines within SDP example deleted.
d) Language regarding media types/subtypes corrected.
Errata ID: 1667
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2009-01-26
Held for Document Update by: Robert Sparks
Section 10, pg.23 says:
RTP packets using this payload format are subject to the security | considerations discussed in the RTP specification [RFC3550], the | base64 specification [RFC4648], and the URI Generic syntax | specification [RFC3986]. [...]
It should say:
RTP packets using this payload format are subject to the security | considerations discussed in the RTP specification [RFC3550] and the | base64 specification [RFC4648]. [...]
Notes:
Rationale:
The published RFC does not make use of embedded or explicit URIs.
Consequently the Security Considerations from RFC 3986 seem to be
irrelevant.
Arguably, the ref. to [RFC4648] only applies to the SDP, not the
RTP packets themselves; further text changes in support of this
observation have been set aside for brevity.
Note:
The entry [RFC3986] in Section 13.1 can be deleted after the
above change.