RFC Errata
Found 1 record.
Status: Verified (1)
RFC 5547, "A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer", May 2009
Source of RFC: mmusic (rai)
Errata ID: 3190
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno CHATRAS
Date Reported: 2012-04-12
Verifier Name: Robert Sparks
Throughout the document, when it says:
Section 9.1., paragraph 7: OLD: --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] NEW: --boundary71 Content-Type: application/sdp Section 9.1., paragraph 9: OLD: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id2@alicepc.example.com> Content-Length: [length of image] Content-Disposition: icon NEW: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id2@alicepc.example.com> Content-Disposition: icon Section 9.2., paragraph 24: OLD: --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] NEW: --boundary71 Content-Type: application/sdp Section 9.2., paragraph 26: OLD: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id3@alicepc.example.com> Content-Length: [length of image] Content-Disposition: icon NEW: --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id3@alicepc.example.com> Content-Disposition: icon
Notes:
A Content-Length header is shown for a body-part within a multipart body. But Content-Length is an HTTP/SIP header, not a IANA-registered MIME header and should therefore not appear at that location in valid examples. The length of a body part within a multipart body is determined by MIME framing. A Content-Length header found for a body-part within a multipart body is meaningless and should be ignored.
This was discussed on both the SIP Implementors and SIP Core mailing lists.