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

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 <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