RFC 3261, "SIP: Session Initiation Protocol", June 2002

Note: This RFC has been updated by RFC 3265, RFC 3853, RFC 4320, RFC 4916, RFC 5393, RFC 5621, RFC 5626, RFC 5630, RFC 5922, RFC 5954, RFC 6026, RFC 6141, RFC 6665, RFC 6878, RFC 7462, RFC 7463, RFC 8217, RFC 8591, RFC 8760, RFC 8898, RFC 8996

Errata ID: 3183
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Bruno CHATRAS
Date Reported: 2012-04-10
Verifier Name: Robert Sparks

Section 23.4.3 says:

         --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required
         Content-Length: 231

It should say:

   --boundary42
         Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
              name=smime.p7m
         Content-Transfer-Encoding: base64
         Content-Disposition: attachment; filename=smime.p7m
            handling=required

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.

Report New Errata