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