At 10:57 AM 4/2/2002 -0500, John C Klensin wrote:
>While the IETF does not design or standardize user interfaces,
>it seems to me that discussion about user interfaces and what
>functions they do, or do not, require is entirely appropriate.
>If we specify a wire ("network interchange") standard that is
>intended to provide some functionality, and that functionality
>cannot be rationally implemented in a user interface,The only problem is that this extended discussion is that it is not serving that purpose. It is not assessing the UI issues correctly, it is confusing protocol issues with implementation issues, AND it is trying to specify UI designs. None of which is constructive to an IETF working group effort. Frankly, both of these problems are persistent in IDN. We start with a topic that has a generic relevance to the work -- although we often engage in that discussion far past the time that is appropriate to a design effort. We get quite a bit of inaccurate technical input. Then we try to specify implementation choices that are a) based on the erroneous assessment, and b) outside the scope of the working group. By way of a counter-example, the fax group managed to do standards work that uses TIFF without having to have protracted debate about cut-and-paste translation to jpeg. (In fact, yes, there was a bit of discussion about such issues at the beginning of the effort, but it was brief and focused and it did not recur years latter.) From an IETF protocol design perspective, that is exactly the same issue as is being discussed at length, here. In other words, John, instead of serving the constructive purpose of validating or challenging real IDNA protocol issues, these sorts of threads merely have the effect of being deprivation of service attacks. >Your repeated comments along the lines of the above risk our >taking the path that you have sometimes claimed was ITU's big >mistake with X.400 -- ignoring both the installed base of >similar and related applications and usability issues. And isn't it strange that, at this point, such an issue would be mentioned here? The IDNA effort is the epitome of paying attention to the installed base. Similarly it has paid an enormous amount of attention to usability. The benefits and limitations of the IDNA approach have been discussed and debated and clarified ad nauseam. After a few years, there is no insight being added by discussing, debating and obscuring it further. >If, for example, it is argued that a particular approach would And upon reviewing your posting a bit, what is significant is that you cite generic issues and generic benefits about this TYPE of debate. However what you do not do is to highlight SPECIFIC benefits that are being derived from this SPECIFIC exchange So let's get concrete: What issues has this exchange raised that are new, valid and poorly understood AND are relevant to the PROTOCOL work of this effort? What problems have been raised that require us to make changes to the specification? If this exchange were happening two years ago, it might be worth indulging in. What real benefits are we deriving from having it now, after specifications have been sent to the IESG? >I don't believe we should change a protocol to benefit one >language while disadvantaging all others, those cases may need >examination too. Fine. Working on the theory that your concern is being mentioned because there is a problem with the IDNA specifications, then what alternative specification are you putting forward or what changes to the current specifications? >Your opinion may differ, and probably does. But I suggest it is >improper to try to suppress discussion by making claims about >what IETF does or does not do when those claims are based on >personal opinion or preference. John, as you well know, IETF working group progress requires constantly enforcing the scope restrictions specified by the charter. Ensuring forward progress often has more to do with limiting scope of discussion than with anything else. Perhaps it is silly of me to worry about the difference between pleasant academic discussions, versus practical engineering work that results in practical protocols developed in a timely manner. For some reason, I have been under the impression that the latter is the purpose of the IETF. d/ ---------- Dave Crocker <mailto:[EMAIL PROTECTED]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
