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

From: "A. Jean Mahoney" <[email-masked]>
Date: Sat, 5 Dec 2015 15:05:12 -0600

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:[email-masked]]
> Sent: 04 December 2015 16:07
> To: [email-masked]; [email-masked]; Gonzalo Camarillo <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Cc: Christer Holmberg <[email-masked]>; [email-masked]
> 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 <[email-masked]>
>
> 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_M7eYpyT35zNp4
>
> 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
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 07 Dec 2015 15:38:07 -0600

Hi,

I am inclined to mark this, as submitted, as "hold for update", which I 
suspect is not what Christer wants to hear. 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 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.

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

Thanks!

Ben.

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

>> 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
>>
>>
>> To: [email-masked]; [email-masked]; Gonzalo 
>> Camarillo <[email-masked]>; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]; [email-masked]; 
>> [email-masked]; [email-masked]
>> 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\\"
>> SIPCORE discussion: 
>> https://mailarchive.ietf.org/arch/msg/sipcore/bn-pRgDyGL2FP_M7eYpyT35zNp4
>>
>> 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.
>>
>> Author(s)           : J. Rosenberg, H. Schulzrinne, G. Camarillo, A. 
>> Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Dec 2015 07:33:52 +0000

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 

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

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 08 Dec 2015 08:11:51 -0600

On 8 Dec 2015, at 1:33, Christer Holmberg wrote:

> Hi,
>
>> I am inclined to mark this, as submitted, as "hold for update", which 
>> I suspect is not what Christer wants to hear.
>
> Correct :)
>
>> 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
> 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.

Sure--but is that what we want it to do? It almost seems to me that if 
the sender wants the body part to be "required", it can say so. Is there 
a reasonable "success friendly" option here?

If the answer to that requires thought or discussion, then maybe this 
should go in a draft, not an eratta.

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

Sounds like a default to "required" will cause even more call failures. 
I guess you might could use that as a lever to force Company X to insert 
C-D. Is that the preferred outcome?

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

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 8 Dec 2015 14:31:36 +0000

Hi,

>>>> 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?
>>>
>>Sure--but is that what we want it to do? It almost seems to me that if the sender wants the body part to be "required", it can say so. Is there a reasonable "success friendly" option here?
>>
>If the answer to that requires thought or discussion, then maybe this should go in a draft, not an eratta.

I can put everything in a draft, if that's what people prefer.

>> Sounds like a default to "required" will cause even more call failures. 

Whoever company is "proven wrong" is expected to fix their deployments, as they can no longer put the blame on the other. The problem is that it is currently not possible to agree on who is wrong (read: who will have to spend resources on fixing their equipment :).

> I guess you might could use that as a lever to force Company X to insert C-D. Is that the preferred outcome?

It doesn't work like that. Company X (and Y) will only fix their equipment if they are proven wrong :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Dec 2015 09:35:48 -0500

I guess Ben's argument here is that there is a straightforward 
work-around (insert a C-D rather than depending on the default) that is 
entirely compliant to the standards and will fix the interop problem.

That still leaves an issue that ought to be resolved, but it reduces the 
urgency of addressing it.

	Thanks,
	Paul

On 12/8/15 9:11 AM, Ben Campbell wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Dec 2015 16:29:20 -0600

On 8 Dec 2015, at 8:35, Paul Kyzivat wrote:

> work-around (insert a C-D rather than depending on the default) that 
> is entirely compliant to the standards and will fix the interop 
> problem.

I wish I could take take credit for that, because it's a much better 
argument than mine :-)

I had more in mind that a default of "required" would encourage people 
to fix implementations due to all the failed calls. I meant that at 
least sort of facetiously.

>
> That still leaves an issue that ought to be resolved, but it reduces 
> the urgency of addressing it.

In any case, it seems to me from discussion so far that we do not have a 
settled consensus on what the default value of the handling parameter 
should be when C-D is not present. That suggests this should be done in 
an I-D, not in an erratum.  If people disagree with that, please speak 
up.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Dec 2015 18:00:40 -0500

On 12/14/15 5:29 PM, Ben Campbell wrote:

> an I-D, not in an erratum.  If people disagree with that, please speak up.

I don't know if we have consensus. But is there any plausible argument 
for why the default should be different when the C-D is missing from 
when it is present but doesn't have a handling parameter?

The only one I can think of would be if each distinct C-D value could 
have its own default value for handling. But that is itself nonsense. 
The purpose of the parameter is for when the recipient doesn't 
understand the value. In that case it won't know the default for that 
parameter.

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Dec 2015 17:21:57 -0600

> when it is present but doesn't have a handling parameter?

I agree that this is already settled for the case where C-D is present 
but with no handling parameter, and consistency is a strong argument. 
But do we think it makes sense to say "If the content is critical, put 
in C-D" rather than "If the content is _not_ critical, put in C-D"? Do 
we really think "required" is or will be the most common case, or that 
the risk of accidentally failing to render critical content is high 
enough to default to failure?

I'm personally on the fence here, if everyone paying attention thinks 
consistency with the default when C-D is present is the correct way to 
handle this, and was the original intent in 3261, then an erratum makes 
sense. But if we feel the need to discuss this further, this probably 
should come in the form of an I-D, even if the final answer is the same.

(If it's not obvious, I question why people decided to make "required" 
the default when C-D is _present_, but that's water under the bridge.)

> understand the value. In that case it won't know the default for that 

I agree with that part.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Dec 2015 19:52:57 -0500

> should come in the form of an I-D, even if the final answer is the same.

Well, in the case where there is no C-D, and the C-T is SDP, then the 
default is handling=required. Is that enough to convince you?

	Thanks,
	Paul

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 14 Dec 2015 19:31:30 -0600

> default is handling=required. Is that enough to convince you?

SDP has a rather privileged place in SIP messages.

But let me turn that around. Are you convinced? Does anyone else thing 
this needs further discussion? If you are, and no one else speaks out 
really soon now[1], I would approve an erratum without the SHOULD to 
MUST bit.

[*] Meaning, "before such an erratum arrives in my email."

Ben.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 14 Dec 2015 23:26:16 -0500

> SDP has a rather privileged place in SIP messages.

Yes, it does. But some effort was made to arrange a consistent set of 
general rules for bodies that is backward compatible with that.

> [*] Meaning, "before such an erratum arrives in my email."

Yes, I'm convinced.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 15 Dec 2015 08:03:03 +0000

Hi,

...

>> [*] Meaning, "before such an erratum arrives in my email."

Me too :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 17 Dec 2015 12:30:50 +0000

Hi,

I have heard no objection, so I will create a new errata, without the SHOULD->MUST change.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 15. joulukuuta 2015 10:03
To: Paul Kyzivat; Ben Campbell
Cc: [email-masked]
Subject: Re: [sipcore] [Technical Errata Reported] RFC3261 (4553)

Hi,

...

>> But let me turn that around. Are you convinced? Does anyone else 
>> thing this needs further discussion? If you are, and no one else 
>> speaks out really soon now[1], I would approve an erratum without the 
>> SHOULD to MUST bit.
>>

Me too :)

Regards,

Christer