Re: [sipcore] [Technical Errata Reported] RFC3261 (4553)

Christer Holmberg <> Tue, 08 December 2015 07:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF8061B3438 for <>; Mon, 7 Dec 2015 23:33:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VBjNPvNRA1HT for <>; Mon, 7 Dec 2015 23:33:55 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 365C31B343E for <>; Mon, 7 Dec 2015 23:33:55 -0800 (PST)
X-AuditID: c1b4fb2d-f79456d000001332-86-566687e1ada8
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id BD.11.04914.1E786665; Tue, 8 Dec 2015 08:33:53 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0248.002; Tue, 8 Dec 2015 08:33:52 +0100
From: Christer Holmberg <>
To: Ben Campbell <>
Thread-Topic: [Technical Errata Reported] RFC3261 (4553)
Thread-Index: AQHRMTeSIo2kj1TwkUCTfZn6k/6AuJ7ArrtA
Date: Tue, 08 Dec 2015 07:33:52 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprBIsWRmVeSWpSXmKPExsUyM2K7n+7D9rQwgwOdkhbzO0+zWzR0rmS1 OPXqNLPF1x+b2BxYPJYs+cnkMWvnExaPL5c/swUwR3HZpKTmZJalFunbJXBl3Fp1mangqFHF v2fL2RoYX2h0MXJySAiYSBy9sI0FwhaTuHBvPVsXIxeHkMBhRonvS6YzQziLGSXaO/ezdjFy cLAJWEh0/9MGaRARUJJ43ryVBaSGWaCLUaJr5TE2kBphAXOJj8edIGosJObdvc0KYRtJLPl0 EcxmEVCR+HxwNxOIzSvgKzF1wQ4WiF3nGSV6+q+AFXEK2Es0nDsAZjMCXff91BqwBmYBcYlb T+YzQVwtILFkz3lmCFtU4uXjf6wQtpLEjw2XWCDqdSQW7P7EBmFrSyxb+JoZYrGgxMmZT1gm MIrNQjJ2FpKWWUhaZiFpWcDIsopRtDi1uDg33chYL7UoM7m4OD9PLy+1ZBMjML4Obvmtu4Nx 9WvHQ4wCHIxKPLwG11PDhFgTy4orcw8xSnAwK4nwtuqmhQnxpiRWVqUW5ccXleakFh9ilOZg URLnbWF6ECokkJ5YkpqdmlqQWgSTZeLglGpg9Nr4xvTg9/PZ+iWnS11vTDpyrDr0ntn/cmX7 +9f3xFh+rZl5SERUV6d/AY9Q3nXJ89fP17l7fpnw7Ptuqzvz997JCzvFtz3mhmrrW3/d7NLr /wWubmXQ67nY+EizOPLwpJoYmdk7jMKOpPPcvd4zn+/hqpNzD/qsjsk+ufOozoeE+ZLJWvW3 ziuxFGckGmoxFxUnAgAchxRTqwIAAA==
Archived-At: <>
Cc: SIPCORE <>, "" <>
Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 08 Dec 2015 07:33:58 -0000


>I am inclined to mark this, as submitted, as "hold for update", which I suspect is not what Christer wants to hear. 

Correct :)

> There are two parts to this:
> Adding "or if the Content-Disposition header field is missing" seems reasonable. I have trouble imagining that the original intent was not exactly that. But I would like to 
>see a bit more discussion about whether this is likely to cause unnecessary transaction failure. Would we expect the UAS to reject any request that had a a body with an 
>unknown MIME type and no content-disposition?

The alternative is having cases where different people make different assumptions, so that the same transaction is sometimes rejected, and sometimes not, depending on what UAS the request reaches. That is not good, and makes it impossible to write specifications etc.

> The change from SHOULD to MUST second guesses the original intent. I don't think we have a reason to think people really meant to write MUST. 
> Rather, I think this is more a (potentially reasonable) change in expectations between then and now. Also, list discussion on that point did not seem conclusive. It seem to me that if people want to make that change, it needs to be in the form of an update.

I am ok to leave the "SHOULD->MUST" part outside the errata, and handle that in an update.

> Christer, you mentioned that this is causing deployment problems. Can you elaborate on the nature of those problems?

Yes. Unfortunately I can't give any company names, so I'll call them company X and company Y.

- Company X UA sends a SIP request with a message body (I don't remember the MIME type, but it doesn't really matter - it is not SDP), *WITHOUT* a C-D header field.
- Company Y UA does NOT support the MIME type, and assumes that the absence of C-D means handling="required". So, company Y rejects the request.
- Company X claims that it is wrong behavior to reject the request, because since there is no C-D header field one should not assume handling="required". Instead, the company Y UA should simply discard the message body.
- Company Y claims that the absence of C-D means handling="required", and that rejecting the request is correct behavior.

This is causing a serious amount of call failures in existing deployments, and has been escalated up the ladders.

Sure, company X and Y could perhaps agree on some fix to handle this. But, later the same issue may later pop up somewhere else. The spec needs to be clear on this, since we are talking about a case that can cause a SIP INVITE request to be rejected.



On 5 Dec 2015, at 15:05, A. Jean Mahoney wrote:

> Hi Christer,
> +Ben and +sipcore since errata aren't sent automatically to the list. 
> The AD pulls the levers on submitted errata.
> Thanks,
> Jean
> On 12/5/15 9:42 AM, Christer Holmberg wrote:
>> Hi chairs,
>> I hope that we can move ahead with this errata asap. It may seem like 
>> a minor issue, but it is actually causing headaches in deployments, 
>> and within the test specification community.
>> People supported the suggestion on the list, and nobody objected, so 
>> I assume it should not cause any problems.
>> Regards,
>> Christer
>> -----Original Message-----
>> From: RFC Errata System []
>> Sent: 04 December 2015 16:07
>> To:;; Gonzalo 
>> Camarillo <>;; 
>> Cc: Christer Holmberg <>; 
>> Subject: [Technical Errata Reported] RFC3261 (4553)
>> The following errata report has been submitted for RFC3261,
>> "SIP: Session Initiation Protocol".
>> --------------------------------------
>> You may review the report below and at:
>> --------------------------------------
>> Type: Technical
>> Reported by: Christer Holmberg <>
>> Section: 20.11
>> Original Text
>> -------------
>> The handling parameter, handling-param, describes how the UAS should 
>> react if it receives a message body whose content type or disposition 
>> type it does not understand.  The parameter has defined values of 
>> \\"optional\\" and \\"required\\".  If the handling parameter is 
>> missing, the value \\"required\\" SHOULD be assumed.  The handling 
>> parameter is described in RFC 3204 [19].
>> Corrected Text
>> --------------
>> The handling parameter, handling-param, describes how the UAS should 
>> react if it receives a message body whose content type or disposition 
>> type it does not understand.  The parameter has defined values of 
>> \\"optional\\" and \\"required\\".  If the handling parameter is 
>> missing, or if the Content-Disposition header field is missing, the 
>> value \\"required\\"
>> MUST be assumed.  The handling parameter is described in RFC 3204 
>> [19].
>> Notes
>> -----
>> SIPCORE discussion: 
>> zNp4
>> Instructions:
>> -------------
>> This erratum is currently posted as "Reported". If necessary, please 
>> use "Reply All" to discuss whether it should be verified or rejected.
>> When a decision is reached, the verifying party (IESG) can log in to 
>> change the status and edit the report, if necessary.
>> --------------------------------------
>> RFC3261 (draft-ietf-sip-rfc2543bis-09)
>> --------------------------------------
>> Title               : SIP: Session Initiation Protocol
>> Publication Date    : June 2002
>> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. 
>> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler
>> Category            : PROPOSED STANDARD
>> Source              : Session Initiation Protocol
>> Area                : Real-time Applications and Infrastructure
>> Stream              : IETF
>> Verifying Party     : IESG