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

[Paul Kyzivat <[e-mail]>]

Hi Keith,

On 8/16/23 4:01 PM, Keith Drage 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.

There have been 7 additions since 3261 was published, with another on 
the way. That is about one every three years. So one might say it isn't 
important. It is certainly something we can discuss.

(In the past you and I have disagreed on the value of IANA registries. I 
guess that continues.)

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

After the initial setup, future updates will require a slightly 
different but no more difficult effort than what is currently required.

	Thanks,
	Paul

> 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