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

[Chris Wendt <[e-mail]>]

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