Subject: [sipcore] (no subject)

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 2 Apr 2012 12:53:25 -0400

Bruno Chatras has pointed out that a number of examples in various SIP-related
RFCs show Content-Length header fields in the headers of body-parts of multipart
entities.  MIME does not define the meaining of such header fields, as the MIME
framing of body parts is done by the boundary markers.

As Dale Moberg has pointed out, these header fields might not be truly incorrect
but merely redundant or "to be ignored".

But given that MIME multipart already frames the body-parts, Content-Length
headers on body-parts are never necessary.

So it seems to me that we should decide on a "best practices" for the use of
Content-Length in the headers of a body part, to clarify the ambiguities in the
specifications, and to state whether it's preferable to include such a Content-Length
or not.

I've appended a list of all the examples carrying such Content-Length headers
that I could find by automated means.

Dale
--------------------------------------------------------------------------------------------------------
RFC 2848

                       The PINT Service Protocol:
   Extensions to SIP and SDP for IP Access to Telephone Call Services

Suspicious line at rfc2848.txt:2195:       Content-Length: 236
Suspicious line at rfc2848.txt:2209:       Content-Length:50
Suspicious line at rfc2848.txt:2268:       Content-Length: 316
Suspicious line at rfc2848.txt:2284:       Content-Length: 172
Suspicious line at rfc2848.txt:2372:    Content-Length: 325
Suspicious line at rfc2848.txt:2387:    Content-Length: 352

Several of these body-part headers are not separated from the
body-part contents by CR-LF-CR-LF.

RFC 3261

                    SIP: Session Initiation Protocol

Suspicious line at rfc3261.txt:11846:         Content-Length: 231

RFC 3892

      The Session Initiation Protocol (SIP) Referred-By Mechanism

Suspicious line at rfc3892.txt:642:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:687:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:702:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:879:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:887:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:938:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:964:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:972:       Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:1056:      Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:1106:      Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:1168:      Content-Length: (appropriate value)
Suspicious line at rfc3892.txt:1196:      Content-Length: (appropriate value)

RFC 3893

                   Session Initiation Protocol (SIP)
                Authenticated Identity Body (AIB) Format

Suspicious line at rfc3893.txt:249:    Content-Length: 147
(This has an extra CR-LF before the body-part headers.)
Suspicious line at rfc3893.txt:263:    Content-Length: 608

RFC 4463

                A Media Resource Control Protocol (MRCP)
              Developed by Cisco, Nuance, and Speechworks

Suspicious line at rfc4463.txt:1705:        Content-Length:176
Suspicious line at rfc4463.txt:1714:        Content-Length:104
Suspicious line at rfc4463.txt:2977:       Content-Length:176
(Also missing the CR-LF after the body part headers.)
Suspicious line at rfc4463.txt:2985:       Content-Length:104

RFC 5547

      A Session Description Protocol (SDP) Offer/Answer Mechanism
                        to Enable File Transfer

Suspicious line at rfc5547.txt:1645:    Content-Length: [length of SDP]
Suspicious line at rfc5547.txt:1670:    Content-Length: [length of image]
Suspicious line at rfc5547.txt:2093:    Content-Length: [length of SDP]
Suspicious line at rfc5547.txt:2118:    Content-Length: [length of image]

RFC 5589

       Session Initiation Protocol (SIP) Call Control - Transfer

Suspicious line at rfc5589.txt:2609:    Content-Length: 2961
(An extra CR-LF in the middle of the body part headers.)
Suspicious line at rfc5589.txt:2677:    Content-Length: 156
(An extra CR-LF in the middle of the body part headers.)
Suspicious line at rfc5589.txt:2696:    Content-Length: 2961

RFC 6086

  Session Initiation Protocol (SIP) INFO Method and Package Framework

Suspicious line at rfc6086.txt:1594:    Content-length: 59
Suspicious line at rfc6086.txt:1620:    Content-length: 59
Suspicious line at rfc6086.txt:1637:    Content-length: 59
Suspicious line at rfc6086.txt:1664:    Content-length: 59

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2012 20:12:26 +0200

[reposting with a subject line]

On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 2 Apr 2012 22:21:38 +0000

Ugh.  Yeah, that's not good for examples to show.
So what's the solution?  Errata?

-hadriel
p.s. I like the "Suspicious Line" thing - all RFC lines are suspicious! ;)

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Apr 2012 18:37:07 -0400

> So what's the solution?  Errata?

Yes, I think the errata process is the right one for this.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 3 Apr 2012 08:39:38 +0200

Hi,

> Yes, I think the errata process is the right one for this.

Agree, eventhough the C-L should cause no conflicts (as long as the value is correct).

And, even if a specific MIME contains another (nested) multipart entry, C-L should not be needed, as the MIME borders are still present.

Regards,

Christer

>>> Bruno Chatras has pointed out that a number of examples in various 
>>> SIP-related RFCs show Content-Length header fields in the headers of 
>>> body-parts of multipart entities.  MIME does not define the meaining 
>>> of such header fields, as the MIME framing of body parts is done by the boundary markers.
>>>
>>> As Dale Moberg has pointed out, these header fields might not be 
>>> truly incorrect but merely redundant or "to be ignored".
>>>
>>> But given that MIME multipart already frames the body-parts, 
>>> Content-Length headers on body-parts are never necessary.
>>>
>>> So it seems to me that we should decide on a "best practices" for 
>>> the use of Content-Length in the headers of a body part, to clarify 
>>> the ambiguities in the specifications, and to state whether it's 
>>> preferable to include such a Content-Length or not.
>>>
>>> I've appended a list of all the examples carrying such 
>>> Content-Length headers that I could find by automated means.
>>>
>>> Dale

---

From: <[email-masked]>
Date: Tue, 3 Apr 2012 11:09:10 +0200

I assume you mean a set of errata to fix the "Suspicious" examples. If Yes, I do agree as well.

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la
> part de Christer Holmberg
> Envoyé : mardi 3 avril 2012 08:40
> À : Paul Kyzivat; Hadriel Kaplan
> Cc : Dale R (Dale) Worley; <[email-masked]>
> Objet : Re: [sipcore] Content-Length in multipart body parts
> 
> Hi,
> 
> And, even if a specific MIME contains another (nested) multipart entry,
> C-L should not be needed, as the MIME borders are still present.
> 
> Regards,
> 
> Christer
> 
> 
> > -hadriel
> >>> -------------------------------------------------------------------
> -
> >>> ------------------------------------
> >>> RFC 2848
> >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 03 Apr 2012 09:52:45 -0400

> I assume you mean a set of errata to fix the "Suspicious" examples. If Yes, I do agree as well.

Yes, that is what I meant.

	Thanks,
	Paul

>> Cc : Dale R (Dale) Worley;<[email-masked]>