[sipcore] (no subject)
"Worley, Dale R (Dale)" <dworley@avaya.com> Mon, 02 April 2012 16:55 UTC
Return-Path: <dworley@avaya.com>
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 991BD21F865D for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 09:55:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.237
X-Spam-Level:
X-Spam-Status: No, score=-98.237 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_SUBJECT=1.762, USER_IN_WHITELIST=-100]
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 CZyRRMYFyYBe for <sipcore@ietfa.amsl.com>; Mon, 2 Apr 2012 09:55:45 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id E15DC21F863F for <sipcore@ietf.org>; Mon, 2 Apr 2012 09:55:44 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AlgIAF7ZeU/GmAcF/2dsb2JhbAA8CaZaAZAvcYEHghASKBMsEhYpQhkGAgIEBAoEAwoahW+BeJ5bnBCLBw+FI2MEm3OKHYMDIoEe
X-IronPort-AV: E=Sophos;i="4.75,358,1330923600"; d="scan'208";a="2498564"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 02 Apr 2012 12:55:44 -0400
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 02 Apr 2012 12:54:30 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.202]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 2 Apr 2012 12:55:43 -0400
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: "sipcore@ietf.org" <sipcore@ietf.org>
Date: Mon, 02 Apr 2012 12:53:25 -0400
Thread-Index: AQHNEPEeoY/AgBxd/UWeeYudwb9dKA==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B22726A09E4@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmoberg@axway.com" <dmoberg@axway.com>, "bruno.chatras@orange.com" <bruno.chatras@orange.com>
Subject: [sipcore] (no subject)
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 16:55:45 -0000
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] (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