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.
Exactly.
> > 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.
And I would agree. I still try to implement everything I write specifications for. The few times I've deviated from this practice I've regretted it. (Can you say RFC 2231?)
> In ARPAnet days, when the user community was small and homogeneous > but > platforms were diverse (different word/character sizes, different > character sets, different limitations of operating systems and > networking hardware), and goals for protocols were modest, merely > being > able to implement a protocol across different platforms was one of > the > biggest barriers to adoption. In that environment, being able to > demonstrate running code on multiple platforms was nearly > sufficient to > demonstrate the viability of a protocol. Besides, since the net was > small, it wasn't terribly hard to make changes should they be found > to > be necessary. > > 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.
Agree on the 8 bit byte part. I wish I could agree on the UTF-8 part, but I have too much (recent) experience to the contrary. It is getting better though, and at least we do have a workablle reasonably universal solution in this space, which is a heck of a lot better than where we were when I first started working in the IETF back in 1991.
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.
Exactly. And arguing about whehere they have or haven't gone away really misses the point. There's always a new impedance mismatch lurking just around the corner.
> These days running code serves as proof-of-concept and also as a > way to > validate the specification. It doesn't say anything about the > quality > of the design - not efficiency, nor usability, nor scalability, nor > security. etc. > > No. It doesn't say much about the efficiency, usability, scalability, or security, but it does say a little, and it gives me, for one, a lot better an idea about where the problems in all those areas lie. Maybe I'm a drooling idiot, and this is the equivalent of having to read aloud, in which case I'm sorry.
To put it another way, the existance of such code says very little, but the experience of writing that code says a lot as long as you're being honest with yourself. Our ability to selld-delude is often part of the problem, but it is much easier to go off the rails with no implementation experience. Ned _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf