On Apr 25, 2013, at 11:58 AM, Adam Roach <[email protected]> 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. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
