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

[Christer Holmberg <[e-mail]>]

Hi,

>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.

Regards,

Christer



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 [mailto:[e-mail]]
>> Sent: 04 December 2015 16:07
>> To: [e-mail]; [e-mail]; Gonzalo 
>> Camarillo <[e-mail]>; [e-mail]; 
>> [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]; [e-mail]; 
>> [e-mail]; [e-mail]
>> Cc: Christer Holmberg <[e-mail]>; 
>> [e-mail]
>> 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:
>> http://www.rfc-editor.org/errata_search.php?rfc=3261&eid=4553
>>
>> --------------------------------------
>> Type: Technical
>> Reported by: Christer Holmberg <[e-mail]>
>>
>> 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: 
>> https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35
>> 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
>>