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

[Paul Kyzivat <[e-mail]>]

[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:
>>
>> .
>