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

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 <rjsparks@nostrum.com>
Sent: sunnuntai 15. toukokuuta 2022 19.59
To: Brian Rosen <br@brianrosen.net>; Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: Christer Holmberg <christer.holmberg@ericsson.com>; Dale R. Worley <worley@ariadne.com>; sipcore@ietf.org
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 <pkyzivat@alum.mit.edu><mailto: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><mailto:sipcore-bounces@ietf.org> On Behalf Of Dale R. Worley
Sent: keskiviikko 11. toukokuuta 2022 5.04
To: Paul Kyzivat <pkyzivat@alum.mit.edu><mailto:pkyzivat@alum.mit.edu>
Cc: sipcore@ietf.org<mailto:sipcore@ietf.org>
Subject: Re: [sipcore] draft-sparks-sipcore-multiple-reasons
Paul Kyzivat <pkyzivat@alum.mit.edu><mailto: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<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore
_______________________________________________
sipcore mailing list
sipcore@ietf.org<mailto:sipcore@ietf.org>
https://www.ietf.org/mailman/listinfo/sipcore