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

[Ranjit Avasarala <[e-mail]>]

I too agree

Regards
Ranjit

On Tue, May 17, 2022 at 4:35 AM Olle E. Johansson <[e-mail]> wrote:

> I am in favor of adoption.
>
> /O
>
> > On 17 May 2022, at 11:30, Chris Wendt <[e-mail]> wrote:
> >
> > I am in favor of adoption.
> >
> >> On May 17, 2022, at 12:57 AM, Paul Kyzivat <[e-mail]>
> wrote:
> >>
> >> 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>
> >>
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >
> > _______________________________________________
> > sipcore mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sipcore
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>