At 03:04 PM 2/3/2002 -0500, Keith Moore wrote:
No, I've said on multiple occasions that it's reasonable and useful to
register extensions that have consensus but don't meet the 2026 requirements
for standards track.
please cite existing specifications for such a process that are used
elsewhere in the IETF community.
I've already done so - the SMTP extensions mechanism.
it seems clear that you do not want to discuss a registry. rather, you
want to impose a standards process on all header name publications.
It seems clear that you want to persuade others by misrepresenting my
views, and resorting to ridicule,
Keith, over the years you have seen me do ridicule more than once. This
exchange isn't even a close approximation to that.
Presumably you do not wish to claim that a participant has no right to
attempt to summarize your views. So if you do not agree with a particular
summary, feel free to provide a detailed correction.
The problem with that line of argument is that it forces me to defend my
own views against your mischaracterization - and in doing so, to move
the discussion away from what the registry should look like to whether
I said such-and-such. I don't consider that an appropriate or useful
direction. (as it is, I'm still spending too much bandwidth arguing
about tangents like X- headers and RFC publication criteria.)
Perhaps we simply disagree. I don't think that documenting stupid
ideas that have no community support is a useful exercise of either
IETF's or the RFC Editor's time, energy, or network bandwidth.
We do it all the time.
Yes, I know. And it eats up a lot of our resources.
CMOT was stupid. So was MIME.
At least MIME had community support.
(CMOT was before my time, so I won't comment on it.)
Perhaps we should to hold off on that kind of assessment and simply
distinguish between standard and non-standard.
I fully agree we should hold off on that kind of assessment. That's
why I want decisions about whether to list a header field deferred
until an assessment can be made about that particular header field.
As for standard vs. non-standard, I don't think that's the best place
to draw the line. I'd far prefer "standards-track, consensus, or
widely deployed" on one hand and everything else on the other.
Doing so just serves to degrade the value of the RFC document series
and confuses the marketplace.
Keith, I do encourage you to review the RFC document series.
I see you haven't abandoned ridicule as an argument strategy.
You are trying to treat the RFC series as a quality assurance process. It
isn't. The IETF standards process is.
I'm arguing that any document series is only valuable if it has
some editorial standards, and that trying to be "too open" with
that series just wastes our time and resources and invites
confusion - even if you and I both know that not all RFCs are
standards, and not all standards are worth implementing.
Now that we have the web, there's no longer a need to provide any
random person with a venue for publication. Folks who can't get
their documents through our editorial process, or don't want to
deal with it, can just publish documents on the web. It's worked
well for Dan - it lets him say whatever he wants without having
to get agreement on it, and the fact that he can do that is a
Good Thing. That doesn't mean that IETF should publish whatever
Dan wants, or whatever you want, or whatever I want.
Similarly, the registry should not automatically include whatever
Dan or you or I want.
On the other hand, I want to use an existing model and you seem to want to
invent a new one.
I am happy to consider existing models. But it's not yet clear to me
that an existing model, without modification, is suitable for this case.
Keith