Re: [sipcore] Content-Length in multipart body parts
Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 02 April 2012 22:37 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 54BD921F874A for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 15:37:15 -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=[AWL=0.000, 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 wl-kUmdUoBAH for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 15:37:14 -0700 (PDT)
Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [76.96.62.80]) by ietfa.amsl.com (Postfix) with ESMTP id 4C19221F86E3 for <sipcore@ietf.org>; Mon, 2 Apr 2012 15:37:14 -0700 (PDT)
Received: from omta16.westchester.pa.mail.comcast.net ([76.96.62.88]) by qmta08.westchester.pa.mail.comcast.net with comcast id tAFc1i0041uE5Es58Ad96D; Mon, 02 Apr 2012 22:37:09 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta16.westchester.pa.mail.comcast.net with comcast id tAd91i00J07duvL3cAd9np; Mon, 02 Apr 2012 22:37:09 +0000
Message-ID: <4F7A2A13.5090002@alum.mit.edu>
Date: Mon, 02 Apr 2012 18:37:07 -0400
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: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <CD5674C3CD99574EBA7432465FC13C1B22726A09E4@DC-US1MBEX4.global.avaya.com> <4F79EC0A.2060201@alum.mit.edu> <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com>
In-Reply-To: <91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "Dale R (Dale) Worley" <dworley@avaya.com>, "<sipcore@ietf.org>" <sipcore@ietf.org>
Subject: Re: [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 22:37:15 -0000
On 4/2/12 6:21 PM, Hadriel Kaplan wrote: > > Ugh. Yeah, that's not good for examples to show. > So what's the solution? Errata? Yes, I think the errata process is the right one for this. Thanks, Paul > -hadriel > p.s. I like the "Suspicious Line" thing - all RFC lines are suspicious! ;) > > > On Apr 2, 2012, at 2:12 PM, Paul Kyzivat wrote: > >> [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 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