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

[Paul Kyzivat <[e-mail]>]

I'm in favor of adopting

On 5/16/22 3:37 PM, Brian Rosen wrote:
> <as chair>
> Could those chiming in, and anyone else please indicate that they are in 
> favor (or not in favor) of adopting this draft, so we have documentation 
> on the original question.
> 
> Brian
> 
> 
>> On May 16, 2022, at 1:34 PM, Christer Holmberg 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi,
>> I agree with Robert that 3326 already by default forbids multiple values.
>> However, I am not sure I understand this “practice shows” thing. If 
>> STIR is the reason we need multiple values, why not say so? What other 
>> practices show that multiple values are needed?
>> Regards,
>> Christer
>> *From:*Robert Sparks <[e-mail] <mailto:[e-mail]>>
>> *Sent:*sunnuntai 15. toukokuuta 2022 19.59
>> *To:*Brian Rosen <[e-mail] <mailto:[e-mail]>>; Paul 
>> Kyzivat <[e-mail] <mailto:[e-mail]>>
>> *Cc:*Christer Holmberg <[e-mail] 
>> <mailto:[e-mail]>>; Dale R. Worley 
>> <[e-mail] <mailto:[e-mail]>>; [e-mail] 
>> <mailto:[e-mail]>
>> *Subject:*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<[e-mail]>
>>         <mailto:[e-mail]>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<[e-mail]>
>>             <mailto:[e-mail]>On Behalf Of Dale R. Worley
>>             Sent: keskiviikko 11. toukokuuta 2022 5.04
>>             To: Paul Kyzivat<[e-mail]>
>>             <mailto:[e-mail]>
>>             Cc:[e-mail] <mailto:[e-mail]>
>>             Subject: Re: [sipcore] draft-sparks-sipcore-multiple-reasons
>>             Paul Kyzivat<[e-mail]>
>>             <mailto:[e-mail]>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
>>             [e-mail] <mailto:[e-mail]>
>>             https://www.ietf.org/mailman/listinfo/sipcore
>>             <https://www.ietf.org/mailman/listinfo/sipcore>
>>
>>         _______________________________________________
>>         sipcore mailing list
>>         [e-mail] <mailto:[e-mail]>
>>         https://www.ietf.org/mailman/listinfo/sipcore
>>         <https://www.ietf.org/mailman/listinfo/sipcore>
>