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

On 5/11/22 9:35 AM, Brian Rosen 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.
I think both of those things are already in 3326?
>   But just a mention is probably okay with me.
>
> Brian
>
>
>> On May 11, 2022, at 9:51 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> 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 <sipcore-bounces@ietf.org> On Behalf Of Dale R. Worley
>>> Sent: keskiviikko 11. toukokuuta 2022 5.04
>>> To: Paul Kyzivat <pkyzivat@alum.mit.edu>
>>> Cc: sipcore@ietf.org
>>> Subject: Re: [sipcore] draft-sparks-sipcore-multiple-reasons
>>> Paul Kyzivat <pkyzivat@alum.mit.edu> 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
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore