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

<as individual>
I’m okay leaving it as is, but I personally would remind readers in this doc.

> On May 15, 2022, at 12:12 PM, Robert Sparks <rjsparks+ietfimap@nostrum.com> wrote:
> 
> 
> 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