Subject: [sipcore] Errata to RFC3261

From: <[email-masked]>
Date: Wed, 4 Jan 2017 16:41:19 +0000

Hi,

I would like to submit an errata to RFC3261 on the following point:

RFC 3261 (section 20 Table 2) states that Content-Type header is not applicable to the CANCEL method (meaning that a CANCEL must not contain a body).

Header field          where   proxy ACK BYE CAN INV OPT REG
_________________________________________________
[...]
Content-Type                                  *     *      -      *     *     *

*: The header field is required if the message body is not empty.
-: The header field is not applicable.

Whereas, in RFC3312 (for preconditions) in case of precondition failure, it is mentioned that CANCEL should contain an SDP :
  " 580 (Precondition Failure) responses and BYE and CANCEL requests,
   indicating failure to meet certain preconditions, SHOULD contain an
   SDP description, indicating which desired status triggered the
   failure.  Note that this SDP description is not an offer or an
   answer, since it does not lead to the establishment of a session.
   The format of such a description is based on the last SDP (an offer
   or an answer) received from the remote UA."

My proposal for the Errata is:

***OLD***
Header field          where   proxy ACK BYE CAN INV OPT REG
_________________________________________________
[...]
Content-Type                                  *     *      -      *     *     *

***NEW***
Header field          where   proxy ACK BYE CAN INV OPT REG
_________________________________________________
[...]
Content-Type                                  *     *     *      *     *     *

Are people fine with this understanding?

Best regards,
Marianne Mohali

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 05 Jan 2017 10:19:12 -0500

<[email-masked]> writes:
> RFC 3261 (section 20 Table 2) states that Content-Type header is not
> applicable to the CANCEL method (meaning that a CANCEL must not
> contain a body).

>    "580 (Precondition Failure) responses and BYE and CANCEL requests,

This isn't really an erratum for 3261 as a clarification that 3312
updates the table in 3261.

But I remember there was a discussion some years ago about maintaining
the tables in 3261 and there was some sort of decision to no longer do
that, as almost every SIP RFC entailed modifying the tables.

Does anyone remember the details of that discussion?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 5 Jan 2017 10:37:32 -0500

> Does anyone remember the details of that discussion?

I can't recall the *details*, but as I remember it the gist was that 
table 2 is insufficient to characterize the nuances that often need to 
be expressed. So, rather than attempt to maintain table 2 the conclusion 
was that documents should express the constraints individually, 
typically with text.

	Thanks,
	Paul

---

From: "A. Jean Mahoney" <[email-masked]>
Date: Thu, 5 Jan 2017 09:57:58 -0600

> was that documents should express the constraints individually,

Here's where the Table 2 discussion is captured:

https://www.ietf.org/mail-archive/web/sipcore/current/msg02230.html

https://www.ietf.org/proceedings/77/minutes/sipcore.html

Jean

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Thu, 5 Jan 2017 16:03:59 +0000

I think this is actually addressing the wrong document.

RFC 3261 is correct in its own right.

It is when it is used in conjunction with RFC 3312 that the problem occurs, and therefore the correction should be made to RFC 3312 to update RFC 3261 in this respect.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 05 January 2017 15:38
To: [email-masked]
Subject: Re: [sipcore] Errata to RFC3261

> Does anyone remember the details of that discussion?

I can't recall the *details*, but as I remember it the gist was that table 2 is insufficient to characterize the nuances that often need to be expressed. So, rather than attempt to maintain table 2 the conclusion was that documents should express the constraints individually, typically with text.

	Thanks,
	Paul

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: <[email-masked]>
Date: Thu, 5 Jan 2017 17:01:54 +0000

Hi,

I don't want to re-open the discussion on the Tables (I also heard that they are now deprecated). 
I agreed that RFC3261 comes first so it should have been stated in RFC3312 that RFC3312 also update the 3261 table. 

I would propose to have an errata to RFC3312 adding this clarification.
Any other view?

BR,
Marianne 

-----Message d'origine-----
De : sipcore [mailto:[email-masked]] De la part de Drage, Keith (Nokia - GB)
Envoyé : jeudi 5 janvier 2017 17:04
À : Paul Kyzivat; [email-masked]
Objet : Re: [sipcore] Errata to RFC3261

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 05 January 2017 15:38
To: [email-masked]
Subject: Re: [sipcore] Errata to RFC3261

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Fri, 6 Jan 2017 09:36:32 -0600

[as individual]

I think the error is in 3312, but it's not the flaw being discussed here.

The error was in allowing 3312 to specify that a CANCEL can have a body. 
While it's not stated normatively in English prose, the line of Table 2 
that you cite has been broadly interpreted to mean that CANCEL cannot 
contain a body. The description of CANCEL handling at proxies does not 
involve any steps that would copy the body from an incoming CANCEL to an 
outgoing one. This has been a long-standing interpretation, dating back 
to approximately the same era as RFC3261's own publication.

See, for example:

https://lists.cs.columbia.edu/pipermail/sip-implementors/2009-January/021232.html

and

https://www.ietf.org/mail-archive/web/sip/current/msg07810.html

What this means is: from a practical perspective, it is highly unlikely 
that a CANCEL body will survive the first proxy it hits. So I think the 
action here is to file an erratum that removes the text from 3312 that 
suggests putting a body in a CANCEL message.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Jan 2017 12:49:55 -0500

+1

On 1/6/17 10:36 AM, Adam Roach wrote:
>> I agreed that RFC3261 comes first so it should have been stated in
>> RFC3312 that RFC3312 also update the 3261 table.
>>
>> It is when it is used in conjunction with RFC 3312 that the problem
>> occurs, and therefore the correction should be made to RFC 3312 to
>> update RFC 3261 in this respect.
>>
>> Keith
>>
>> be expressed. So, rather than attempt to maintain table 2 the
>> conclusion was that documents should express the constraints
>> individually, typically with text.
>>
>>     Thanks,
>>     Paul
>>
>> Ce message et ses pieces jointes peuvent contenir des informations
>> confidentielles ou privilegiees et ne doivent donc
>> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
>> recu ce message par erreur, veuillez le signaler
>> a l'expediteur et le detruire ainsi que les pieces jointes. Les
>> messages electroniques etant susceptibles d'alteration,
>> This message and its attachments may contain confidential or
>> privileged information that may be protected by law;

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 06 Jan 2017 14:30:19 -0500

<[email-masked]> writes:
> I don't want to re-open the discussion on the Tables (I also heard
> that they are now deprecated).  I agreed that RFC3261 comes first so
> it should have been stated in RFC3312 that RFC3312 also update the
> 3261 table.
>

Relative to Jean Mahoney's message, the decision is to deprecate Table 2
in RFC 3261, and defer to text descriptions.  As I understand it, the
text description of the use of bodies in CANCEL given in RFC 3312 is
clear, and clearly supersedes the discussion in RFC 3261, so there is no
need for an erratum.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 6 Jan 2017 15:55:31 -0500

Dale,

> clear, and clearly supersedes the discussion in RFC 3261, so there is no

I think you are missing Adam's point. Remember that CANCEL is 
hop-by-hop. If you were generate a CANCEL with SDP and pass it to a 
proxy that doesn't have specific support for 3312 then there is no 
reason to expect that the SDP would be passed on downstream.

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Mon, 09 Jan 2017 11:16:41 -0500

> to approximately the same era as RFC3261's own publication.

Ugh.  Though looking at 3312, I see this:

   580 (Precondition Failure) responses and BYE and CANCEL requests,
   indicating failure to meet certain preconditions, SHOULD contain an
   SDP description, indicating which desired status triggered the
   failure.  Note that this SDP description is not an offer or an
   answer, since it does not lead to the establishment of a session.
   The format of such a description is based on the last SDP (an offer
   or an answer) received from the remote UA.

which suggests that SDP bodies should be put in 580 responses and BYE
requests as well as CANCEL requests, and all of those would be
unexpected in the prior technology.

It sounds like the problem is that the mechanism proposed in that
paragraph just won't work -- and that's more than an erratum, it needs a
technical solution, if only to state that the recovery process (whatever
it is) that the SDP description is supposed to enable won't happen.

Dale

---

From: Adam Roach <[email-masked]>
Date: Mon, 9 Jan 2017 14:42:53 -0600

[as individual]

>     or an answer) received from the remote UA.

Right. That's the passage that is causing me some distress.

> unexpected in the prior technology.

Well, bodies in BYEs and in error responses are accommodated by the base 
specification. Bodies in CANCEL are not.

> it is) that the SDP description is supposed to enable won't happen.

We've apparently made it over 14 years without this coming up at a SIPit 
or as a problem on the sip-implementors list. I'm not certain there's a 
need for some technical solution here -- I think a simple correction 
that removes the CANCEL body would clear up the confusion that Marianne 
identified.

/a

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 10 Jan 2017 11:14:37 -0500

> that removes the CANCEL body would clear up the confusion that Marianne 

Heh -- "We don't need to solve that problem." is the simplest and most
efficient solution to a problem.

Though theoretically, deliberately reverting a feature isn't an erratum,
an erratum sounds like the most effective way of *publishing* this
change in practice.

So let's call for consensus to amend 3312 to remove the specification of
a body in CANCEL and, for the time being, to publish that amendment as
an erratum...

Dale

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Wed, 11 Jan 2017 03:19:36 +0000

I do not believe the decision to deprecate the tables ever made its way into any formal documentation.

As far as I remember the agreement only went as far as what to do for new header fields and methods, and did not change existing material, which would have had to wait for a revision of the original documents.

Formally, RFC 3312 can only change normative requirements in RFC 3261 if it updates it.

Keith

PS: The whole discussion above is irrelevant if we follow Adam's subsequent mail.

-----Original Message-----
From: Dale R. Worley [mailto:[email-masked]] 
Sent: 06 January 2017 19:30
To: [email-masked]
Cc: Drage, Keith (Nokia - GB) <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [sipcore] Errata to RFC3261

> I would propose to have an errata to RFC3312 adding this clarification.

Relative to Jean Mahoney's message, the decision is to deprecate Table 2 in RFC 3261, and defer to text descriptions.  As I understand it, the text description of the use of bodies in CANCEL given in RFC 3312 is clear, and clearly supersedes the discussion in RFC 3261, so there is no need for an erratum.

Dale