Subject: Re: [Gen-art] Gen-art LC review of draft-saintandre-impp-call-info-02

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 7 May 2013 18:35:50 +0300

Hi,

yes, fixing registry issues are orthogonal to progressing this draft.

Cheers,

Gonzalo

On 26/04/2013 2:09 AM, Cullen Jennings (fluffy) wrote:
> 
> On Apr 25, 2013, at 11:58 AM, Adam Roach <[email-masked]> wrote:
> 
>> On 4/24/13 09:19, Peter Saint-Andre wrote:
>>> Hi Elwyn, thanks for the review.
>>>
>>> On Apr 23, 2013, at 2:12 PM, Elwyn Davies wrote:
>>>> Generic comment about SIP Header Field Parameters registry: For the uninitiated this registry is rather opaque.  Some parameters, such as the Call-Info purpose parameter for which an extra value is defined here, have predefined values.  However the predefined values themselves are not in the registry and just giving a whole RFC reference for places where values are defined is not very helpful. For example, in the case of Call-Info, the initial predefined values of purpose are buried in the Call-Info rule in the ABNF in Section 25.1 of RFC 3261;  also, Section 20.9 describes the predefined values (such as "icon") as 'parameters' rather than values of 'purpose'.  It would probably be helpful to either improve the references in the registry table or actaully quote the possible predefined values in the table.
>>>>
>>>
>>> I agree, but as you say that's an issue with the SIP Header Field Parameters registry in general. I started to go down the path of fixing the registry as a whole, but I think I'd rather leave that for 3261bis to tackle (sometime before the heat death of the universe).
>>
>> Yes, the registry is a mess, largely due to the rather whimsical preferences -- which would vary from year to year -- of the SIP community regarding which fields needed a registry and which did not. It's grown to be the way it is somewhat organically, and I agree that the overall SIP registry is something of a mess.
>>
>> I'm not sure we need to wait for a 3261bis to fix things, as I doubt we could find someone with the fortitude to take on an effort that large. It might be worth finding someone to work on a "registry overhaul" document that attempts to make the whole thing more coherent. I'll be keeping this in mind as a potential SIPCORE item.
>>
>> /a
> 
> +1
> 
> More importantly, I don't think this draft could reasonably take on cleaning up that mess. 
> 
>