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

[Mary Barnes <[e-mail]>]

I support the adoption of this draft as a WG deliverable.

Regards,
Mary

On Mon, May 16, 2022 at 2:38 PM Brian Rosen <[e-mail]> 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]> 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]>
> *Sent:* sunnuntai 15. toukokuuta 2022 19.59
> *To:* Brian Rosen <[e-mail]>; Paul Kyzivat <[e-mail]
> >
> *Cc:* Christer Holmberg <[e-mail]>; Dale R. Worley <
> [e-mail]>; [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]>
> <[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]> <[e-mail]> On
> Behalf Of Dale R. Worley
> Sent: keskiviikko 11. toukokuuta 2022 5.04
> To: Paul Kyzivat <[e-mail]> <[e-mail]>
> Cc: [e-mail]
> Subject: Re: [sipcore] draft-sparks-sipcore-multiple-reasons
> Paul Kyzivat <[e-mail]> <[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]
> 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
>