Re: [sipcore] Establishing an IANA registry for Call-Info protocol parameter values

["Olle E. Johansson" <[e-mail]>]

> On 17 Aug 2023, at 02:18, Paul Kyzivat <[e-mail]> wrote:
> 
> Brian,
> 
> On 8/16/23 6:23 PM, Brian Rosen wrote:
>> As I said, we have several defined in emergency services, and wished we had a registry to declare them.  There are no RFCs that define them, but there are published, referenceable standards.
> 
> Hmm. That puts an interesting spin on this. If those defs aren't in the RFCs that are currently referenced in the existing registry, then there is no way for a party unaware of them to discover those values. And, in the future, somebody else intending to define a new value might accidentally reuse one of your existing values!
> 
Brians information is a clear indication that we need the registry for interoperability. Agree fully with Paul here.

/O
> 	Thanks,
> 	Paul
> 
>> Brian
>>> On Aug 16, 2023, at 4:01 PM, Keith Drage <drageke=[e-mail]> wrote:
>>> 
>>> As to the why - Is this a header field parameter that more values are likely to be defined in the future, or where there are other usages not documented by RFCs out in the field. If the answer is no, then there is no point. The minimum already exists by pointing to a list of RFCs.
>>> 
>>> I would anly add to the how in that the actual documentation is fairly simple, and the data is merely an instruction to IANA, so its status would be informational. As to where it is documented, as such it should take path that requires least administrative effort.
>>> 
>>> Keith
>>> 
>>> On 16/08/2023 19:06, Paul Kyzivat wrote:
>>>> [Changing subject since this is no longer about draft-ietf-sipcore-callinfo-rcd.]
>>>> 
>>>> Just thinking about what changes are required to do this...
>>>> 
>>>> First, *why*?
>>>> 
>>>> The registry for the Call-Info purpose parameter currently has references to eight RFCs, each of which defines one or more purpose values. Getting a list of all defined values requires reading every one of those. Finding the definition of a particular value requires a search until you find it. This is not ideal.
>>>> 
>>>> In theory this problem could exist for other header field parameters. But none of the others have more than three references, so the problem is less severe for them. So I'm not inclined to propose a general solution.
>>>> 
>>>> Now, *how*?
>>>> 
>>>> We have header field positional parameters that have their own registry of values. (E.g., "Reason Protocols".) But I'm not finding any header field keyword parameters (generic-param format, the kind listed in Header Field Parameters and Parameter Values) that have their own registry of values. Is there an existing example I have missed? If not then we have to make it up.
>>>> 
>>>> I think we could follow what is done for positional header field parameters, such as the "Reason Protocols" registry for the Reason header field. We would need an RFC to establish this registry and initialize it with the grandfathered values.
>>>> 
>>>> This RFC would have IANA considerations that define the registry policy and provide a template to be used by future documents that want to add another Call-Info purpose. I suggest that it is probably better as a stand-alone RFC rather than as an appendage to draft-ietf-sipcore-callinfo-rcd. This new RFC should revise the entry for the Call-Info purpose parameter, so that it only references RFC3261 and this new RFC,removing the references to all the past RFCs that have defined new values.  (That will guide future updaters to the new IANA registration parameters.)
>>>> 
>>>> Then the new registry ("Call-Info Purposes"?) will contain a reference to the defining RFC for each defined purpose.
>>>> 
>>>> Does the above seem right? Any better ideas?
>>>> 
>>>>     Thanks,
>>>>     Paul
>>>> 
>>>> On 8/15/23 10:48 AM, Brian Rosen wrote:
>>>>> We have used new Call-Info purpose parameters in emergency services a lot.  For example, we have an Incident-Id, and a Call-IId that has different semantics to the SIP call id.
>>>>> The lack of a registry is unfortunate.
>>>>> 
>>>>> I would be happy to contribute text for this document that does the registry, or write a short draft that does it, or add it to a draft we’re working on in ecrit that defines a bunch of new registries.
>>>>> 
>>>>> Brian
>>>>> 
>>>>>> On Aug 14, 2023, at 12:43 PM, Paul Kyzivat <[e-mail]> wrote:
>>>>>> 
>>>>>> .
>>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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
> 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore