On Fri Mar 24 19:50:15 2006, Keith Moore wrote:
In other words, there are working groups where a substantial
number > of people involved in the discussion are not only not
going to be > implementing the proposals, but don't actually do any
kind of > implementation within the "sphere" - we're talking about
people > discussing the precise semantics of some HTTP extension
who aren't > involved in doing any webserver related programming,
or some people > discussing an email issue who limit their
interaction with email to > having an email address.
I don' t have a problem with that. IMHO we tend to design with too
little regard for the needs of end users, and we need more
input from knowledgable users, rather than less.
That input needs to be present in defining the problem, not the
solution.
Such input would also be useful in evaluating a potential solution.
As for developing the solution, good solutions tend to be developed by
small design teams of clueful people. Often, it takes more than
developer clue to make a good design team - protocol design clue,
operational clue, security clue, human factors clue, etc. would all be
useful. But I agree that it's the rare user who would make
significant contributions to a protocol design team.
Or, if you prefer, people are talking and not doing the "running
code" bit.
It may be that we place too much emphasis on running code in IETF
today.
I'd say we place too little.
[...]
We have fewer platforms, and they're all running with the same 8-bit
byte, (or as close as makes no difference), and they all do UTF-8
easily, let alone ASCII, so yes, that kind of problem has largely
gone away.
However, if you're extending IMAP, say, there's a large number of
IMAP servers out there which are, internally, massively different
beasts, so the "in my day" argument merely highlights that problems
move, they don't go away.
I guess I would say that testing of new features on a wide variety of
platforms, while sometimes useful or even necessary, usually isn't
sufficient to validate the design of a protocol or extension. By all
means let's do the testing when it's appropriate to do so. But let's
not take the results of those tests by themselves to mean the protocol
is good. I've seen lots of arguments of the form "X is implemented,
therefore it's good" and that's often a totally bogus argument. (e.g.
for X == DKIM)
It's weird, because I thought that pretty well everyone implemented
stuff to this level. For a long time - years - it never occured to me
that PoC and probably even deployed implementations didn't exist for
some specifications, let alone those going onto the standards track.
Scary. Though of course, our process doesn't require that at Proposed.
I think the assumption was that we'd get early feedback on
implementations before deployment, and that things wouldn't get widely
deployed before Draft. Of course, it hasn't worked out that way.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf