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

Yes agree, explicitly state why a new protocol was justified and SIP had potential issues for future reference.

-Chris

> On May 11, 2022, at 10:35 AM, Brian Rosen <br@brianrosen.net> 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 <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
> 
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore