> --On Friday, March 06, 2009 14:08 -0800 Kurt Zeilenga > <Kurt.Zeilenga@xxxxxxxxx> wrote: > >... > > Okay, so we're being overly anal here. Like we can control > > the world of protocol extensions. > Kurt, > While I agree (and strongly so), there is lots of precedent for > the IESG rejecting parameter registrations because of distaste > for a particular extension, presumably in the hope that "no > registered value" will imply "the unpopular extension idea goes > away". There are indeed lots of precedents for this. And speaking as someone who, as media types reviewer, has had had to clean up the mess as best I could when we were overly restrictive with one of these things, there is also precedent that doing this can be a REALLY bad idea. > From a process standpoint, there is no difference > between "we won't let you have a value because there are > identified serious technical flaws and risks with the extension" > and "the IESG finds you and/or your proposal unattractive and > cannot determine that there is community consensus to the > contrary, so you don't get the value". Exactly so. > Of course, if the requester is at all determined, denying the > value assignment rarely works. Instead, it leads to squatting > on parameter values which, in any sort of limited space, is a > sure path to interoperability problems with applications that > use the values differently and may have registered them. And in the case of a large space, the registry ends up being incomplete, thereby diminishing its value. If the unregistered value ends up getting deployed, the lack of registry information, including but not limited to security considerations, can lead to operational problems. And depending on the shape of the parameter space there can still be collisions leading to interop problems. > And that is probably just a long way of saying "like we can > control...". But in believing we can we can things even worse. Ned _______________________________________________ Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf