> 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@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf