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

[Keith Drage <[e-mail]>]

I was not necessarily disagreeing on the need, merely phrasing the 
question that people should be asking themselves before they agreed.

I have not enough information to know if more values are likely in the 
future, but others in the groups surely do have some input on this. I 
will be perfectly happy either way.

Keith

On 16/08/2023 22:06, Paul Kyzivat wrote:
> 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
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore