On Thu, Jan 9, 2014 at 4:17 PM, Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
wrote:
On 1/9/2014 11:40 AM, David Conrad wrote:
The problem is that this issue keeps repeating, particularly in (shall we
say) non-technical venues. In a private message I semi-seriously suggested
someone should write an RFC that deprecates classes other than IN.
However, I'm beginning to think this might not be that bad of an idea --
at least there would be a document that the non-technical folks who keep
raising the issue could be pointed at...
The premise to your line of thinking is that deprecating other classes
will reduce these periodic demands for new name spaces.
One of the benefits of having had so many of these cycles of demands, over
the last 15+ years, is that we can see that straightforward technical
discussion and explanation does not dissuade the proponents. They want what
they want and they reject information that counters what they want.
As I've become too fond of suggesting, the real requirement here is to
move the work back onto those seeking the change.
It is /their/ burden to do the work of proposing and specifying the
change, in sufficient technical detail.
It is /their/ burden to do the detail work of explaining how it can
be viable.
It is /their/ burden to recruit sufficient community support.
For the rest of us, the only burden is to put the burden back onto those
folk. Rather than saying "that won't work" and rather than trying to
explain why it won't work, and rather than trying to narrow their
opportunities for making criticisms, we merely need to recite some version
of the above litany.
If they are so certain what they want is viable, they need to do the work
of making it viable.
+1
This is the way to deal with technical issues. Just lay out the facts and
make sure that every fact that is laid out is completely supportable.
When people draw the conclusion that 'X is impossible', people like me take
that as a challenge.
--
Website: http://hallambaker.com/