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

From: Elwyn Davies <[email-masked]>
Date: Tue, 23 Apr 2013 21:12:50 +0100

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-saintandre-impp-call-info-02.txt
Reviewer: Elwyn Davies
Review Date: 23 April 2013
IETF LC End Date: 14 May 2013
IESG Telechat date: (if known) -

Summary: Ready.  See the generic issue with the IANA registry mentioned 
below.

Major issues: None

Minor issues: None

Nits/editorial comments:
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.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Apr 2013 08:19:10 -0600

Hi Elwyn, thanks for the review.

On Apr 23, 2013, at 2:12 PM, Elwyn Davies wrote:

> Summary: Ready.  See the generic issue with the IANA registry  
> mentioned below.
>
> Major issues: None
>
> Minor issues: None
>
> Nits/editorial comments:
> 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).

Peter

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Apr 2013 12:58:32 -0500

On 4/24/13 09:19, Peter Saint-Andre wrote:
>> here, have predefined values.  However the predefined values 
>> 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.
>>
>

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

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Thu, 25 Apr 2013 23:09:37 +0000

On Apr 25, 2013, at 11:58 AM, Adam Roach <[email-masked]> 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.