Re: [sipcore] draft-sparks-sipcore-multiple-reasons

[Chris Wendt <[e-mail]>]

Hi Robert,

That is fine with me, I can get on board with simple is better for this document.

Thanks.

-Chris

> On May 15, 2022, at 6:58 PM, Robert Sparks <[e-mail]> wrote:
> 
> 
> On 5/12/22 10:00 AM, Chris Wendt wrote: 
>> Yes agree, explicitly state why a new protocol was justified and SIP had potential issues for future reference. 
> 
> So, I can, but as I replied to Paul, I really don't think saying that something this draft doesn't do could be a problem if someone did it in the future. 
> 
> The draft _already_ explicitly states that 'Practice shows it is useful to allow multiple values with the same protocol value'. The document is currently STIR free, except for the short bit in the acknowledgements. An explanation of why STIR needs this change really belongs in a STIR document referencing this one. 
> 
> Let's either keep this draft short (really, I have a goal to make this as short of a document as possible) or change our earlier thinking and shift this text into a STIR document that updates SIP (not what I want to do at all). 
> 
> RjS 
> 
> 
>> 
>> -Chris 
>> 
>>> On May 11, 2022, at 10:35 AM, Brian Rosen <[e-mail]> <mailto:[e-mail]> wrote: 
>>> 
>>> <as individual> 
>>> Aha!  I was confused.  This makes clear what you intended.  No harm in noting the issue in the doc.  I would expressly forbid multiple values in current protocols with a note as to why.  But just a mention is probably okay with me. 
>>> 
>>> Brian 
>>> 
>>> 
>>>> On May 11, 2022, at 9:51 AM, Paul Kyzivat <[e-mail]> <mailto:[e-mail]> wrote: 
>>>> 
>>>> Its clear that this will be the case initially. My question is a hypothetical. At some time in the future someone may find a reason they want to use multiple reasons with SIP or another pre-existing protocol. At that point they might propose an update to allow that for SIP. At that point there would be a potential backward compatibility problem. 
>>>> 
>>>> I'm only asking that this document discuss the issue and provide guidance for the future. For instance it might ban such changes for pre-existing protocols. Or it might just point out that an update to allow such for a protocol address the problem as part of the update. 
>>>> 
>>>>     Thanks, 
>>>>     Paul 
>>>> 
>>>> On 5/11/22 2:30 AM, Christer Holmberg wrote: 
>>>>> I thought the idea was to allow multiple protocols ONLY if the protocol value explicitly allows it (e.g., "STIR"). 
>>>>> But, the change would NOT allow multiple instances of "SIP". 
>>>>> Regards, 
>>>>> Christer 
>>>>> -----Original Message----- 
>>>>> From: sipcore <[e-mail]> <mailto:[e-mail]> On Behalf Of Dale R. Worley 
>>>>> Sent: keskiviikko 11. toukokuuta 2022 5.04 
>>>>> To: Paul Kyzivat <[e-mail]> <mailto:[e-mail]> 
>>>>> Cc: [e-mail] <mailto:[e-mail]> 
>>>>> Subject: Re: [sipcore] draft-sparks-sipcore-multiple-reasons 
>>>>> Paul Kyzivat <[e-mail]> <mailto:[e-mail]> writes: 
>>>>>> If an update is made to an existing protocol definition that does 
>>>>>> allow multiple reasons, it could break existing implementations. 
>>>>> A possible "upward compatibility" mechanism is to retain the requirement that existing protocol names still have only one value, and define a second protocol name to carry the other values that are semantically associated with the existing protocol name.  Thus one might have: 
>>>>>     Reason: SIP ;cause=200 ;text="Call completed elsewhere", 
>>>>>             SIP-M ;cause=200.1 ;text="Call completed by voicemail", 
>>>>>             SIP-M ;cause=200.1.17 ;text="Subscriber's voicemail" 
>>>>> Older implementations would likely discard both the SIP-M values and process the SIP value as expected. 
>>>>> Dale 
>>>>> _______________________________________________ 
>>>>> sipcore mailing list 
>>>>> [e-mail] <mailto:[e-mail]> 
>>>>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore> 
>>>> _______________________________________________ 
>>>> sipcore mailing list 
>>>> [e-mail] <mailto:[e-mail]> 
>>>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore> 
>>> _______________________________________________ 
>>> sipcore mailing list 
>>> [e-mail] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>