RFC Errata
Found 10 records.
Status: Verified (1)
RFC 4566, "SDP: Session Description Protocol", July 2006
Note: This RFC has been obsoleted by RFC 8866
Source of RFC: mmusic (rai)
Errata ID: 1089
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Colin Perkins
Date Reported: 2007-12-06
Verifier Name: Cullen Jennings
Date Verified: 2009-01-08
Section 9 says:
IP6-multicast = hexpart [ "/" integer ] IP6-address = hexpart [ ":" IP4-address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG
It should say:
IP6-multicast = IP6-address [ "/" integer ] IP6-address = 6( h16 ":" ) ls32 / "::" 5( h16 ":" ) ls32 / [ h16 ] "::" 4( h16 ":" ) ls32 / [ *1( h16 ":" ) h16 ] "::" 3( h16 ":" ) ls32 / [ *2( h16 ":" ) h16 ] "::" 2( h16 ":" ) ls32 / [ *3( h16 ":" ) h16 ] "::" h16 ":" ls32 / [ *4( h16 ":" ) h16 ] "::" ls32 / [ *5( h16 ":" ) h16 ] "::" h16 / [ *6( h16 ":" ) h16 ] "::" h16 = 1*4HEXDIG ls32 = ( h16 ":" h16 ) / IP4-address
Notes:
Correct IPv6 ABNF.
Status: Reported (4)
RFC 4566, "SDP: Session Description Protocol", July 2006
Note: This RFC has been obsoleted by RFC 8866
Source of RFC: mmusic (rai)
Errata ID: 5595
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Gavin Scallan
Date Reported: 2019-01-08
Section 5 says:
An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf [email protected] (Jane Doe) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
It should say:
An example SDP description is: v=0 o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.example.com/seminars/sdp.pdf [email protected] (Jane Doe) c=IN IP4 224.2.17.12/127 a=recvonly t=2873397496 2873404696 m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 99 a=rtpmap:99 h263-1998/90000
Notes:
In section 5 it indicates that the SDP lines MUST appear in the exact order given at the top of Page 9.
The order that is shown indicates that the Session Attributes appear before the Time Description.
However in the example included in this section which explains that Media Attributes have precedence over Session Attributes for a media stream contradicts the order as the Session Attribute of sendonly is included below the Time Description.
Either the example is incorrect, or the normative description is poorly explained and some variability in the order of lines in the SDP is allowed.
Errata ID: 6022
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Megan Ruggiero
Date Reported: 2020-03-16
Section 9 says:
; sub-rules of 'e=', see RFC 2822 for definitions email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe "<" phone ">" / phone
It should say:
; sub-rules of 'e=', see RFC 2822 for definitions email-address = address-and-comment / dispname-and-address / addr-spec address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">" ; sub-rules of 'p=' phone-number = phone *SP "(" 1*email-safe ")" / 1*email-safe 1*SP "<" phone ">" / phone
Notes:
There's an inconsistency between the definitions of dispname-and-address and phone-number. I am not sure if this is intentional or not, and in practice this doesn't change what's matched (as email-safe includes spaces), but I thought it'd be worth mentioning since I myself got tripped up when translating the grammar.
Alternatively, perhaps 1*SP should be removed from dispname-and-address.
Errata ID: 4903
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: Jxck
Date Reported: 2017-01-12
Section 9 says:
; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields connection-field bandwidth-fields time-fields key-field attribute-fields media-descriptions connection-field = [%x63 "=" nettype SP addrtype SP connection-address CRLF] ;a connection field must be present ;in every media description or at the ;session-level media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields )
It should say:
; SDP Syntax session-description = proto-version origin-field session-name-field information-field uri-field email-fields phone-fields [connection-field] bandwidth-fields time-fields key-field attribute-fields media-descriptions connection-field = %x63 "=" nettype SP addrtype SP connection-address CRLF ;a connection field must be present ;in every media description or at the ;session-level media-descriptions = *( media-field information-field *connection-field bandwidth-fields key-field attribute-fields )
Notes:
in BNF of SDP,
connection-field itself is optional [0, 1], but media-description has multiple [0,) connection-field.
it seems conflict, because multiple of optional fields doesn't finish because multiple filed can't find when to end.
so change connection-field itself not optional (remove []) and, replace session-descriptions connection-field as optional.
Errata ID: 5183
Status: Reported
Type: Editorial
Publication Format(s) : TEXT
Reported By: no space before encoding parameter in rtpmap value
Date Reported: 2017-11-14
Section 6. SDP Attr says:
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]
It should say:
a=rtpmap:<payload type> <encoding name>/<clock rate>[/<encoding parameters>]
Notes:
rtpmap requires format below
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2
no space between clock rate and optional parameter
Status: Held for Document Update (2)
RFC 4566, "SDP: Session Description Protocol", July 2006
Note: This RFC has been obsoleted by RFC 8866
Source of RFC: mmusic (rai)
Errata ID: 1795
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Leandro Lucarella
Date Reported: 2009-06-19
Held for Document Update by: Robert Sparks
Section 9 says:
decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2*(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
It should say:
decimal-uchar = DIGIT / POS-DIGIT DIGIT / ("1" 2(DIGIT)) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
Notes:
The "*" is removed from the 3rd line.
The current RFC accepts any number starting with "1" and followed by
2 or more digits (like 1000 or 123456789) as a valid "decimal-uchar"
because of this error, because "1" 2*(DIGIT) means 2 or more digits
following a "1". The correction, 2(DIGIT) means *exactly* 2 digits
following a "1", which covers the range 100-199.
Errata ID: 2517
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Victor S. Osipov
Date Reported: 2010-09-13
Held for Document Update by: Robert Sparks
Section 5.14 says:
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.
It should say:
If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers. When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, and these payload formats are listed in order of preference, with the first format listed being preferred; in that case the first acceptable payload format from the beginning of the list SHOULD be used for the session.
Notes:
The word ‘default‘ is improper here, because payload format is not implied, but explicitly indicated. This may lead to a misunderstanding and confusion.
The corrections are proposed in order to avoid confusion and to give complete clear instructions in case of multiple payload type numbers indicated.
Status: Rejected (3)
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.
Errata ID: 3278
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Riccardo Bernardini
Date Reported: 2012-07-03
Rejected by: Robert Sparks
Date Rejected: 2012-11-04
Section 5 says:
At page 9: Media description, if present m= (media name and transport address)
It should say:
Media description, if present m=* (media name and transport address)
Notes:
A '*' is added making "m=" lines optional
Rationale:
The description about media lines in section 5, page 9 is conflicting with the ABNF syntax of media-description in Section 9, page 40
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
According to the ABNF grammar, an SDP description can have zero "m=" lines, but according to the description at page 9, at least one line must be present. Note that the conflict could be solved also by replacing the media-descriptions definition with
media-descriptions = 1*( media-field ... )
but at page 8 (still Section 5) it is said
An SDP session description consists of a session-level section
followed by zero or more media-level sections. ...
^^^^^^^^^^^^^^^^^^^^^^^^
so, I guess that the ABNF grammar is correct.
--VERIFIER NOTES--
Please see the discussion at http://www.ietf.org/mail-archive/web/mmusic/current/msg09398.html
Errata ID: 4769
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Petr Vaněk
Date Reported: 2016-08-08
Rejected by: Ben Campbell
Date Rejected: 2016-08-08
Section 5.3. says:
5.3. Session Name ("s=") s=<session name> The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s= " SHOULD be used (i.e., a single space as the session name).
It should say:
5.3. Session Name ("s=") s=<session name> The "s=" field is the textual session name. There MUST be one and only one "s=" field per session description. The "s=" field MUST NOT be empty and SHOULD contain ISO 10646 characters (but see also the "a=charset" attribute). If a session has no meaningful name, the value "s=-" SHOULD be used (i.e., a single dash as the session name).
Notes:
In 3rd paragraph of section 5. is written: whitespace MUST NOT be used on either side of the "=" sign, which is incosistent with subsection 5.3. Therefore I suggest to use "-" (single dash) instead of " " (single space) for sessions without meaningful name.
--VERIFIER NOTES--
The mmusic working group is in the process of updating RFC 4566. If the issue applies to the updated text ( https://datatracker.ietf.org/doc/draft-ietf-mmusic-rfc4566bis/ ), please send comments to mm[email protected] rather than file errata reports against RFC 4566.