[sipcore] Content-Length in multipart body parts
Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 02 April 2012 18:12 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64E9A21F8638 for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 11:12:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aJZqsn6DGVi1 for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 11:12:28 -0700 (PDT)
Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by ietfa.amsl.com (Postfix) with ESMTP id E7F4A21F8603 for <sipcore@ietf.org>; Mon, 2 Apr 2012 11:12:27 -0700 (PDT)
Received: from omta07.westchester.pa.mail.comcast.net ([76.96.62.59]) by qmta06.westchester.pa.mail.comcast.net with comcast id t69w1i0081GhbT8566CU4K; Mon, 02 Apr 2012 18:12:28 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta07.westchester.pa.mail.comcast.net with comcast id t6CU1i00K07duvL3T6CUbw; Mon, 02 Apr 2012 18:12:28 +0000
Message-ID: <4F79EC0A.2060201@alum.mit.edu>
Date: Mon, 02 Apr 2012 20:12:26 +0200
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <CD5674C3CD99574EBA7432465FC13C1B22726A09E4@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B22726A09E4@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [sipcore] Content-Length in multipart body parts
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Apr 2012 18:12:29 -0000
[reposting with a subject line] On 4/2/12 6:53 PM, Worley, Dale R (Dale) wrote: > 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 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >
- [sipcore] (no subject) Colin Pons
- [sipcore] (no subject) Dale R Worley
- [sipcore] (no subject) Worley, Dale R (Dale)
- [sipcore] Content-Length in multipart body parts Paul Kyzivat
- Re: [sipcore] Content-Length in multipart body pa… Hadriel Kaplan
- Re: [sipcore] Content-Length in multipart body pa… Paul Kyzivat
- Re: [sipcore] Content-Length in multipart body pa… Christer Holmberg
- Re: [sipcore] Content-Length in multipart body pa… bruno.chatras
- Re: [sipcore] Content-Length in multipart body pa… Paul Kyzivat
- Re: [sipcore] Content-Length in multipart body pa… bruno.chatras
- Re: [sipcore] Content-Length in multipart body pa… Paul Kyzivat
- Re: [sipcore] Content-Length in multipart body pa… bruno.chatras
- Re: [sipcore] Content-Length in multipart body pa… Paul Kyzivat
- Re: [sipcore] Content-Length in multipart body pa… Worley, Dale R (Dale)
- Re: [sipcore] draft-ietf-sipcore-rfc4244bis-10: q… Brett Tate
- [sipcore] (no subject) Gottfried, Hal F