Re: [sipcore] Content-Length in multipart body parts

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 25 June 2012 15:01 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 7C31B11E8080 for <sipcore@ietfa.amsl.com>; Mon, 25 Jun 2012 08:01:36 -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 sCVjnf2FpOmV for <sipcore@ietfa.amsl.com>; Mon, 25 Jun 2012 08:01:35 -0700 (PDT)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [76.96.59.228]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21F11E8079 for <sipcore@ietf.org>; Mon, 25 Jun 2012 08:01:33 -0700 (PDT)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id SdA51j0090ldTLk5Ff1bLq; Mon, 25 Jun 2012 15:01:35 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta04.westchester.pa.mail.comcast.net with comcast id Sf1X1j01607duvL3Qf1X8A; Mon, 25 Jun 2012 15:01:32 +0000
Message-ID: <4FE87D4B.4010603@alum.mit.edu>
Date: Mon, 25 Jun 2012 11:01:31 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: bruno.chatras@orange.com
References: <CD5674C3CD99574EBA7432465FC13C1B22726A09E4@DC-US1MBEX4.global.avaya.com><4F79EC0A.2060201@alum.mit.edu><91DCD0FE-A00F-4A10-8230-63F367B4E3AF@acmepacket.com> <4F7A2A13.5090002@alum.mit.edu> <25107_1340623449_4FE84A59_25107_5423_1_88CAD1D4E8773F42858B58CAA28272A002BB31@PEXCVZYM12.corporate.adroot.infra.ftgroup> <4FE87275.4020401@alum.mit.edu> <1743_1340635431_4FE87927_1743_11418_1_88CAD1D4E8773F42858B58CAA28272A002C19B@PEXCVZYM12.corporate.adroot.infra.ftgroup>
In-Reply-To: <1743_1340635431_4FE87927_1743_11418_1_88CAD1D4E8773F42858B58CAA28272A002C19B@PEXCVZYM12.corporate.adroot.infra.ftgroup>
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, 25 Jun 2012 15:01:36 -0000

On 6/25/12 10:43 AM, bruno.chatras@orange.com wrote:

>> How many times do we need to repeat that examples are non-normative?
>>
>> People who implement to examples rather than the specs almost always run
>> into problems. IMO the way this gets fixed is for someone who encounters
>> an interop problem due to someone else having implemented to an example
>> rather than the spec needs to call this out as an error and request that
>> it be fixed. Anybody who argues that their implementation is justified
>> because it is compliant with an example won't get support for that
>> position.
>>
>> The implementers who have this problem most likely won't have looked at
>> the errata either.
> [BC] Their customers can tell them to look at the errata when requesting them to fix the error.
>
> If they do look at the errata, will changing the
>> status from "Held" to "Accepted" change their behavior?
> [BC] That's what I understood from at least one of them...

IIUC you are saying that the following happened:

- Customer complains to implementer: Your implementation is wrong, and 
is breaking my system because you are using Content-Length in a body 
part. I claim that this is incorrect because according to the MIME specs 
C-L is not a valid header.

- Implementer responds: my use of C-L is valid, because it is shown in 
an example in RFC 6086.

- Customer responds to implementer: examples aren't normative. Please 
cite some normative text that permits C-L here. Also, the use of C-L in 
that example has already been reported to be an error.

- Implementer responds: I still consider the example to be valid because 
the error is still in state "held" rather than "accepted". I don't need 
to cite normative text for my use.

!@#$%^&*(

IMO such an implementer is either new, and needs to be clued in to how 
standards work, or else he is a lost cause. If he is a lost cause, then 
you need a neutral 3rd party to mediate.

	Thanks,
	Paul