--On Friday, March 06, 2009 14:08 -0800 Kurt Zeilenga
<Kurt(_dot_)Zeilenga(_at_)Isode(_dot_)com> 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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf