RFC Errata
Found 4 records.
Status: Verified (1)
RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006
Source of RFC: mmusic (rai)
Errata ID: 5416
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Simon Rankine
Date Reported: 2018-07-06
Verifier Name: Orie Steele
Date Verified: 2024-04-01
Section 3.2.5 says:
a=source-filter incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9
It should say:
a=source-filter: incl IN IP6 FF0E::11A 2001:DB8:1:2:240:96FF:FE25:8EC9
Notes:
Normative text in section 3 requires a colon after the source-filter attribute, but the ipv6 example in section 3.2.5 omits this colon.
Status: Rejected (3)
RFC 4570, "Session Description Protocol (SDP) Source Filters", July 2006
Source of RFC: mmusic (rai)
Errata ID: 55
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 6 says:
Purpose: See this document Reference: This document Values: See this document, and registrations below
It should say:
Purpose: See RFC 4632 Reference: RFC 4632 Values: See RFC 4632
Notes:
The filled out SDP attribute registration template in the IANA
Considerations (Section 6) on page 10 contains improper wording
-- either just being garbage (there are no 'registrations below'
in the RFC), or getting inappropriate when extracted from the RFC
and included in a stand-alone IANA document.
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)
Errata ID: 802
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 1 says:
Applications and hosts may also share the source-filter information with network elements (e.g., with routers using [IGMPv3]) so they can potentially perform the traffic | filtering operation further "upstream," closer to the source(s).
It should say:
Applications and hosts may also share the source-filter information with network elements (e.g., with routers using [IGMPv3]) so they can potentially perform the traffic | filtering operation further "upstream", closer to the source(s).
Notes:
quoting style
from pending
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)
Errata ID: 804
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-11-01
Rejected by: Ross Finlayson
Date Rejected: 2006-11-01
Section 1 says:
Use of source-filters do not corrupt the ASM semantics but provide more control for receivers, at their discretion.
It should say:
| Use of source-filters does not | corrupt the ASM semantics but provides more control for receivers, at their discretion.
Notes:
from pending
--VERIFIER COMMENT--
Thanks for the comments. It would have been nice if these very minor
errors could have been corrected prior to RFC publication. However,
I'm not convinced that they are significant enough to warrant a RFC
Errata note. (If, however, the RFC editor disagrees, then I could
certainly go ahead and do this.)