RFC Errata
RFC 4566, "SDP: Session Description Protocol", July 2006
Note: This RFC has been obsoleted by RFC 8866
Source of RFC: mmusic (rai)
Errata ID: 57
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-09
Rejected by: Colin Perkins
Date Rejected: 2006-11-22
(1) typo
On page 7 of RFC 4566, Section 4.6 says:
The SDP specification recommends the use of the ISO 10646 character
| sets in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole.
It should say:
The SDP specification recommends the use of the ISO 10646 character
| set in the UTF-8 encoding [5] to allow many different languages to
be represented. However, to assist in compact representations, SDP
also allows other character sets such as ISO 8859-1 to be used when
desired. Internationalisation only applies to free-text fields
(session name and background information), and not to SDP as a whole.
(2) inconsistent specification
Contrary to the text in Section 4.6 (see above), Section 5 of RFC 4566
specifies, at the bottom of page 7:
An SDP session description is entirely textual using the ISO 10646
character set in UTF-8 encoding. SDP field names and attribute names
use only the US-ASCII subset of UTF-8, but textual fields and
attribute values MAY use the full ISO 10646 character set. [...]
These conflicting specifications might become a source of
interoperability problems, and therefore, the conflict should be
resolved by a clarification !!!
Note: Subsequent text in sections 5.* specifies behaviour related
to the "a=charset" attribute required if other charsets than UTF-8
are used in certain fields; therefore, the latter exclusive UTF-8
rule is most probably too restrictive and hence inappropriate.
(3) misleading text / inconsistency + typo (missing article)
Still in Section 5, the second-to-last paragraph on page 8 of RFC 4566
says:
An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level
| section. Each media-level section starts with an "m=" line and
| continues to the next media-level section or end of the whole session
description. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value.
The second sentence does not accomodate for an important corner case
mentioned in the first sentence, and thus should be amended with
similar wording as below. The third sentence is imprecise as well,
because the "or" does not uniquely select the 'right' condition.
It should better say:
An SDP session description consists of a session-level section
followed by zero or more media-level sections. The session-level
part starts with a "v=" line and continues to the first media-level
| section (or the end of the whole description, whichever comes first).
Each media-level section starts with an "m=" line and continues to
| the next media-level section or the end of the whole session
| description - whichever comes first. In general, session-level
values are the default for all media unless overridden by an
equivalent media-level value.
(4) significant mis-specification
In the "Session description" block, on top of page 9, the RFC says:
c=* (connection information -- not required if included in
all media)
b=* (zero or more bandwidth information lines)
It should say:
c=* (connection information -- not required if included in
all media descriptions)
b=* (zero or more bandwidth information lines)
Rationale:
Strictly differentiating between "media" and "media description"
is always required to avoid confusion! ...
And connection information is rarely (if ever) seen in the media!
(5) improper wording related with IP addresses
IP addresses (in IPv4 and IPv6) are always assigned to an interface,
not to a host or 'machine'. Therefore, a Standards Track RFC
should never talk about '*the* IP address of a machine'.
FQDNs are also not necessarily unique for a 'machine', e.g. a server
having multiple, 'role-based' FQDNs.
Therefore, in Section 5.2, the last paragraph on page 11,
| <unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either
| the fully qualified domain name of the machine or the dotted-
| decimal representation of the IP version 4 address of the machine.
| For an address type of IP6, this is either the fully qualified
domain name of the machine or the compressed textual
| representation of the IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
| SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
should say:
| <unicast-address> is an address of the machine from which the
session was created. For an address type of IP4, this is either
| a fully qualified domain name of the machine or the dotted-
| decimal representation of an IP version 4 address of the machine.
| For an address type of IP6, this is either a fully qualified
domain name of the machine or the compressed textual
| representation of an IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
| SHOULD be given unless this is unavailable, in which case a
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
(6) improper term used
a)
Section 5.6 twice uses the term, "conference", where IMHO, according
to the definitions given in Section 2, the term, "session" should
be used. This change makes the text better conform with the
classification of the "e=" and "p=" lines on page 9, as well.
The first textual paragraph of Section 5.6, on page 13, says:
The "e=" and "p=" lines specify contact information for the person
| responsible for the conference. This is not necessarily the same
| person that created the conference announcement.
It should say:
The "e=" and "p=" lines specify contact information for the person
| responsible for the session. This is not necessarily the same person
| that created the session announcement.
b)
Another instance of this issue occurs in Section 5.7, at the bottom
of page 14. There, the RFC says:
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
| which multicast packets sent in this conference will be sent. TTL
values MUST be in the range 0-255. [...]
It should say:
o Sessions using an IPv4 multicast connection address MUST also have
a time to live (TTL) value present in addition to the multicast
address. The TTL and the address together define the scope with
| which multicast packets sent in this session will be sent. TTL
values MUST be in the range 0-255. [...]
c)
Finally, the last sentence of the second paragraph of Section 5.13,
on page 21,
[...]. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
to the conference as a whole rather than to individual media.
should say, accordingly:
[...]. Attribute
fields can also be added before the first media field; these
"session-level" attributes convey additional information that applies
| to the session as a whole rather than to individual media.
(7) clarification
The second paragraph of Section 5.9, on page 17, says:
The first and second sub-fields give the start and stop times,
respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds
since 1900 [13]. To convert these values to UNIX time, subtract
decimal 2208988800.
To make the time base unique and absolute, the time zone (UTC) needs to
be specified.
Hence, the RFC should say:
The first and second sub-fields give the start and stop times,
respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds
| since 1900, UTC [13]. To convert these values to UNIX time, subtract
decimal 2208988800.
(8) typo (missing article)
The second text paragraph of section 5.10, on page 18, says:
To make description more compact, times may also be given in units of
days, hours, or minutes. [...]
It should say:
| To make the description more compact, times may also be given in
units of days, hours, or minutes. [...]
(9) legacy term not replaced
Since the advent of SIP and the Offer/Answer Model for SDP, it is
no more appropriate, in a general context, to name a
'session description' just a 'session announcement'.
The final paragraph of Section 5.11, on page 19, says:
If a session is likely to last several years, it is expected that the
session announcement will be modified periodically rather than
transmit several years' worth of adjustments in one session
announcement.
It should say therefore:
If a session is likely to last several years, it is expected that the
| session description will be modified periodically rather than
| transmitting several years' worth of adjustments in one session
| description.
(10) clarification of 'charset' related terminology, plus typos
Section 5.13 makes use of legacy terminology related to character
sets and "charsets". It should use the stable, IESG policy based
IETF terminology.
a)
Hence, the first paragraph on page 22:
Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
values are to be interpreted as in ISO-10646 character set with UTF-8
encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset
rather than in ISO-10646.
should better say:
Attribute values are octet strings, and MAY use any octet value
except 0x00 (Nul), 0x0A (LF), and 0x0D (CR). By default, attribute
| values are to be interpreted as in the ISO-10646 character set with
UTF-8 encoding. Unlike other text fields, attribute values are NOT
normally affected by the "charset" attribute as this would make
comparisons against known values problematic. However, when an
attribute is defined, it can be defined to be charset dependent, in
which case its value should be interpreted in the session charset
rather than in UTF-8.
Note: RFC 1815 has been deprecated; 'ISO-10646' is *not* considered a
"charset", whereas 'UTF-8' is.
b)
In Section 6, at the bottom of page 28, the RFC says:
a=charset:<character set>
This specifies the character set to be used to display the
session name and information data. By default, the ISO-10646
character set in UTF-8 encoding is used. If a more compact
representation is required, other character sets may be used.
For example, the ISO 8859-1 is specified with the following SDP
attribute:
a=charset:ISO-8859-1
The above headline should say:
a=charset:<charset>
or perhaps even better:
a=charset:<IANA-charset>
and the text body above should be changed to say:
| This specifies the character set and encoding ("charset") to be
| used for the session name and information data. By default,
| the ISO-10646 character set in UTF-8 encoding (charset "UTF-8")
is used. If a more compact representation is required, other
| charsets may be used. For example, the ISO 8859-1 charset is
specified with the following SDP attribute:
[...]
Note: The session description does not determine how parts of it
are *displayed* (theres may be some transcoding used, and fonts
or typefaces, etc., the charset must only be specified for SDP.)
The subsequent text on page 29,
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
with IANA, such as ISO-8859-1. The character set identifier is
a US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
Note that a character set specified MUST still prohibit the use
of bytes 0x00 (Nul), 0x0A (LF), and 0x0d (CR). Character sets
requiring the use of these characters MUST define a quoting
mechanism that prevents these bytes from appearing within text
fields.
should be changed to say (fixing typos as well):
This is a session-level attribute and is not dependent on
charset. The charset specified MUST be one of those registered
| with IANA, such as ISO-8859-1. The charset identifier is a
US-ASCII string and MUST be compared against the IANA
identifiers using a case-insensitive comparison. If the
identifier is not recognised or not supported, all strings that
are affected by it SHOULD be regarded as octet strings.
| Note that a charset specified MUST still prohibit the use of
| bytes 0x00 (NUL), 0x0A (LF), and 0x0D (CR). Charsets requiring
the use of these characters MUST define a quoting mechanism
that prevents these bytes from appearing within text fields.
(11) language related issues, plus typos
The RFC text on pp. 29/30 does not properly distinguish between, and
messes up, the specifics of session content (and its language[s]) and
the session *description* content (and the language[s] used therein).
Note: I show more context than absolutely necessary to perform the
recommended changes, to make these better understandable.
a)
On mid-page 29, RFC 4566 says:
a=sdplang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
| multiple languages in the session description or media use
| multiple languages, in which case the order of the attributes
| indicates the order of importance of the various languages in
| the session or media from most important to least important.
(The last half-sentence is wrong and inappropriate.)
It should better say:
a=sdplang:<language tag>
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
language for the session description. As a media-level
attribute, it specifies the language for any media-level SDP
information field associated with that media. Multiple sdplang
attributes can be provided either at session or media level if
| multiple languages in the session or media description use
| multiple languages.
b)
Skipping one paragraph, the next one says:
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
| when a session is of sufficient scope to cross geographic
boundaries where the language of recipients cannot be assumed,
| or where the session is in a different language from the
locally assumed norm.
It should say:
The "sdplang" attribute value must be a single RFC 3066
language tag in US-ASCII [9]. It is not dependent on the
charset attribute. An "sdplang" attribute SHOULD be specified
| when a session description is of sufficient scope to cross
geographic boundaries where the language of recipients cannot
| be assumed, or where the session description is in a different
language from the locally assumed norm.
c)
Next, in the explanations for:
a=lang:<language tag>
extending from page 29 to page 30,
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
<<page break>>
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
| the session description or media use multiple languages, in
which case the order of the attributes indicates the order of
importance of the various languages in the session or media
from most important to least important.
should be corrected to say:
This can be a session-level attribute or a media-level
attribute. As a session-level attribute, it specifies the
default language for the session being described. As a media-
level attribute, it specifies the language for that media,
<<page break>>
overriding any session-level language specified. Multiple lang
attributes can be provided either at session or media level if
| the session or media use multiple languages, in which case the
order of the attributes indicates the order of importance of
| the various languages in the session or media, from most
important to least important.
Note: In the meantime (since the publication of RFC 4566), RFC 3066
has been superseded by RFC 4646 plus RFC 4647, now together denoted
as BCP 47.
(12) typo
On page 31, in the second paragraph of Section 7, RFC 4566 says:
[...]. Many different transport protocols may be used to
distribute session description, and the nature of the authentication
will differ from transport to transport. [...]
It should say:
[...]. Many different transport protocols may be used to
| distribute session descriptions, and the nature of the authentication
will differ from transport to transport. [...]
(13) SDP Grammar issues (ABNF in Section 9, p. 39 ff.),
a)
The rule for 'repeat-interval' (page 41) could easily have
re-used (incorporated) the 'integer' rule:
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
is equivalent to:
repeat-interval = integer [fixed-len-time-unit]
b)
The rule for FQDN, at the bottom of page 42, is wrong;
FQDNs really should allow up to 255 characters!
v
| FQDN = 4*(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
Because details are not gived (can be found at other places),
this rule should perhaps be only minimally corrected to say:
| FQDN = *(alpha-numeric / "-" / ".")
; fully qualified domain name as specified
; in RFC 1035 (and updates)
At a minimum, serious issues should be addressed,
e.g. (2), (10), (11), and the ABNF mistake (13b).
Notes:
from pending
--VERIFIER COMMENT--
While you raise a number of valid minor issues, I see nothing which
needs urgent attention or correction. I'll keep a record of these
issues, to be included if there is a revision to RFC 4566, but I see
no need to submit an errata note to the RFC Editor.