Re: [sipcore] Warren Kumari's No Objection on draft-ietf-sipcore-multiple-reasons-01: (with COMMENT)

[Robert Sparks <[e-mail]>]

On 10/27/22 11:55 AM, Paul Wouters wrote:
> On Oct 27, 2022, at 10:34, Robert Sparks <[e-mail]> wrote:
>> Inline.
>>
>>> I was going to ballot DISCUSS on this, but I see that Paul W has beat me to the
>>> punch.
>>>
>>> If a "legacy" implementation gets multiple values for a protocol, it is likely
>>> to be OK with this, or is it likely to explode in a massive fireball? I have
>>> absolutely no idea how many implementations there are, how restrictive their
>>> parsers are, etc (AKA, "Nah, we thought about this, and it's all good" is
>>> enough to satisfy me).
>> Yes, we thought about this.
>>
>> We tested this at SIPits back in the day, and implementations ignore any Reason header field values with protocols they don't know about, even if there are multiple values for the same unknown-to-them protocol.
> But that statement doesn’t cover multiple values for protocols they do understand. Do they pick the first ? Just overwrite so it ends up picking the last one ?

If you are asking about older implementations that only know of the 
protocols discussed in RFC3326 (which talks about using SIP and ISUP 
(Q.850)) receiving a message that has, say, more than one ISUP Reason 
header field value: This was tested and things did not just crash. 
RFC3326, like most of SIP, doesn't define what to do if something 
violates a MUST/MUST NOT, but testing showed that reasonable things 
happened, usually in the form of ignoring both values Some 
implementations would 4xx the request, which is allowed, but silly in 
the long run. None did something like "pick one and pretend the other 
didn't exist". But all of that is entirely RFC3326's topic to talk 
about, not this document, which is explicitly not a bis. This isn't the 
place to start trying to add clarification to RFC3326.

If you are asking about older implementations receiving multiple Reason 
header field values with a protocol they are unfamiliar with, we tested 
that, and they universally ignored them, even if there were multiples.

Newer implementations, I'm told informally, are getting tested in labs, 
and the industry that is going to be deploying, e.g, 
https://datatracker.ietf.org/doc/draft-ietf-stir-identity-header-errors-handling/ 
are not expressing concerns with the state of the implementations or the 
efficacy of deployment.


> Hence my question on whether ordering could matter.
>
> Paul