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

<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