Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883)

From: "Ben Campbell" <[email-masked]>
Date: Mon, 12 Dec 2016 09:43:57 -0600

Do people have thoughts on this errata report?

My initial inclination that, while the suggestion may be technically 
correct, the mentioned SHOULD merely parrots the similar SHOULD in RFC 
3311 (UPDATE method), which is where the authoritative text lives.  
(This is why I've started pushing back on redundant 2119 keywords ;-)  )

Has anyone observed breakage in the wild due to a peer not doing this?

Thanks!

Ben.

On 12 Dec 2016, at 4:31, RFC Errata System wrote:

> The following errata report has been submitted for RFC3312,
> "Integration of Resource Management and Session Initiation Protocol 
> (SIP)".
>
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=3312&eid=4883
>
> --------------------------------------
> Type: Technical
> Reported by: Shraddha Soni <[email-masked]>
>
> Section: 11
>
> Original Text
> -------------
> Therefore, a user agent
>    including preconditions in the SDP MUST support the PRACK and 
> UPDATE
>    methods. Consequently, it MUST include the "100rel" [7] tag in the
>    Supported header field and SHOULD include an Allow header field 
> with
>    the "UPDATE" tag [5].
>
> Corrected Text
> --------------
> Therefore, a user agent
>    including preconditions in the SDP MUST support the PRACK and 
> UPDATE
>    methods. Consequently, it MUST include the "100rel" [7] tag in the
>    Supported header field and MUST include an Allow header field with
>    the "UPDATE" tag [5].
>
> Notes
> -----
> As stated in first line in the mentioned paragraph, the user agent 
> MUST support the UPDATE method, hence even in Allow header field also, 
> UPDATE method MUST be included.
>
> As per RFC 2119
> "SHOULD -This word, or the adjective "RECOMMENDED", mean that there
>    may exist valid reasons in particular circumstances to ignore a
>    particular item, but the full implications must be understood and
>    carefully weighed before choosing a different course.   "
>
> Here in precondition case, whether any chance of ignoring the UPDATE 
> method happens ?
>
> As per RFC 3261
> Section 8.2.1 states -
> "The Allow header field MUST list the set of methods supported by the 
> UAS
>    generating the message. ... If the method is one supported by the 
> server, processing continues."
>
> and also in RFC 3261 Sections 20.5 states-
> "All methods, including ACK and CANCEL, understood by the UA MUST be
>    included in the list of methods in the Allow header field, when
>    present."
>
> 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
> can log in to change the status and edit the report, if necessary.
>
> --------------------------------------
> RFC3312 (draft-ietf-sip-manyfolks-resource-07)
> --------------------------------------
> Title               : Integration of Resource Management and Session 
> Initiation Protocol (SIP)
> Publication Date    : October 2002
> Author(s)           : G. Camarillo, Ed., W. Marshall, Ed., J. 
> Rosenberg
> Category            : PROPOSED STANDARD
> Source              : Session Initiation Protocol
> Area                : Real-time Applications and Infrastructure
> Stream              : IETF
> Verifying Party     : IESG

---

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 12 Dec 2016 18:12:19 +0200

Hi Ben,

yes, this is a classic example of a redundant 2119 keyword.

Cheers,

Gonzalo

On 12/12/2016 5:43 PM, Ben Campbell wrote:
>>    including preconditions in the SDP MUST support the PRACK and UPDATE
>>    Supported header field and SHOULD include an Allow header field with
>>    the "UPDATE" tag [5].
>>
>> Corrected Text
>> --------------
>> Therefore, a user agent
>>    including preconditions in the SDP MUST support the PRACK and UPDATE
>> "The Allow header field MUST list the set of methods supported by the UAS
>> Author(s)           : G. Camarillo, Ed., W. Marshall, Ed., J. Rosenberg

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 12 Dec 2016 10:24:04 -0600

I'm inclined to mark this as "hold for update", since a real fix would 
involve (at least) two RFCs, and I assume this is not actively causing 
problems for implementors.

If anyone is aware of related implementation/deployment problems, please 
speak up.

Thanks!

Ben.

On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Dec 2016 12:31:02 -0500

I have always been troubled by the detailed semantics of Allow and other 
similar headers.

IIUC this originated in HTTP. In that context its meaning is 
transactional - the requester is indicating what headers it will allow 
in the response to this one request. In that context it is fine.

But in SIP the meaning has been broadened. It is assumed to apply to 
usage beyond the current transaction - to future transactions, even 
requests going in the other direction. But it has never been made clear 
how much beyond the current transaction it applies. It is impossible to 
indicate precisely which headers will be allowed in the future because 
many of them are allowed only in certain contexts. Also, a UA may 
support a *lot* of header fields, and may not want to list them all 
simply to reduce the size of the message.

In the current case, indicating support of the option (100rel) implies 
that a set of header fields will be used. Listing all of those in Allow 
is at least redundant.

I guess this rambling doesn't really affect the conclusion on this 
erratum. I'm not sure there is a practical solution to this problem. 
Perhaps we ought to clarify that Allow in a request MUST indicate header 
fields allowed in responses to that request, and SHOULD (MAY?) also 
indicate header fields that might be allowed in requests directed toward it.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 12 Dec 2016 18:49:59 +0000

Agree.

Keith

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]] 
Sent: 12 December 2016 16:24
To: Gonzalo Camarillo <[email-masked]>
Cc: SIPCORE <[email-masked]>; Jonathan Rosenberg <[email-masked]>; [email-masked]; [email-masked]; [email-masked]; Drage, Keith (Nokia - GB) <[email-masked]>; [email-masked]
Subject: [ALU] Re: [sipcore] [Technical Errata Reported] RFC3312 (4883)

I'm inclined to mark this as "hold for update", since a real fix would involve (at least) two RFCs, and I assume this is not actively causing problems for implementors.

If anyone is aware of related implementation/deployment problems, please speak up.

Thanks!

Ben.

On 12 Dec 2016, at 10:12, Gonzalo Camarillo wrote:

>>> MUST support the UPDATE method, hence even in Allow header field 
>>> also, UPDATE method MUST be included.
>>>
>>> As per RFC 2119
>>> and also in RFC 3261 Sections 20.5 states- "All methods, including 
>>> ACK and CANCEL, understood by the UA MUST be
>>> rejected. When a decision is reached, the verifying party can log in 
>>> to change the status and edit the report, if necessary.
>>>

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Mon, 12 Dec 2016 19:31:16 +0000

Yes, but seriously, is this something we need to worry about now. Getting this perfect is not something we should be addressing in an errata, and is if we opened an update, is the world really going to implement the update.

Keith

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: 12 December 2016 17:31
To: [email-masked]
Subject: Re: [sipcore] [Technical Errata Reported] RFC3312 (4883)

I have always been troubled by the detailed semantics of Allow and other similar headers.

IIUC this originated in HTTP. In that context its meaning is transactional - the requester is indicating what headers it will allow in the response to this one request. In that context it is fine.

But in SIP the meaning has been broadened. It is assumed to apply to usage beyond the current transaction - to future transactions, even requests going in the other direction. But it has never been made clear how much beyond the current transaction it applies. It is impossible to indicate precisely which headers will be allowed in the future because many of them are allowed only in certain contexts. Also, a UA may support a *lot* of header fields, and may not want to list them all simply to reduce the size of the message.

In the current case, indicating support of the option (100rel) implies that a set of header fields will be used. Listing all of those in Allow is at least redundant.

I guess this rambling doesn't really affect the conclusion on this erratum. I'm not sure there is a practical solution to this problem. 
Perhaps we ought to clarify that Allow in a request MUST indicate header fields allowed in responses to that request, and SHOULD (MAY?) also indicate header fields that might be allowed in requests directed toward it.

	Thanks,
	Paul

On 12/12/16 10:43 AM, Ben Campbell wrote:
>> use "Reply All" to discuss whether it should be verified or rejected. 
>> When a decision is reached, the verifying party can log in to change 
>> the status and edit the report, if necessary.
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 12 Dec 2016 15:25:30 -0500

> Yes, but seriously, is this something we need to worry about now. Getting this perfect is not something we should be addressing in an errata, and is if we opened an update, is the world really goin…

I agree it isn't something to address in the errata, except as some 
context for if/when this eventually gets taken up.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 13 Dec 2016 09:29:25 +0200

I also agree with your assessment and proposed way forward Ben. Just do it!

Cheers,

Gonzalo

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 13 Dec 2016 09:44:53 -0500

Of course, Ben's suggestion is the best way to handle the erratum
(assuming there are no problems in practice).

> I have always been troubled by the detailed semantics of Allow and other 

My memory is that there was a discussion some years back in which all
the angles of this problem were discussed, with the conclusion being
that when the UAC sends a request, the headers it has received in
previous requests and responses are only hints because the current
request may go to a different destination.  I.e., the scope of the
information provided by headers is always unclear.  So the UAC should
usually simply attempt to use the extensions that it desires to use, and
have an appropriate fallback strategy if that fails.

Dale

---

From: "Ben Campbell" <[email-masked]>
Date: Tue, 13 Dec 2016 09:26:00 -0600

It is done.

Ben.

On 13 Dec 2016, at 1:29, Gonzalo Camarillo wrote:

>> Cc: SIPCORE <[email-masked]>; Jonathan Rosenberg 
>> <[email-masked]>; [email-masked]; 
>> [email-masked]; [email-masked]; Drage, Keith (Nokia - GB) 
>> <[email-masked]>; [email-masked]
>> I'm inclined to mark this as "hold for update", since a real fix 
>> would involve (at least) two RFCs, and I assume this is not actively 
>> causing problems for implementors.
>>
>>>> (This is why I've started pushing back on redundant 2119 keywords 
>>>> ;-)
>>>>  )
>>>>