[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] URL encoding in html page
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
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
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
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
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
>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.
Dave Crocker <mailto:firstname.lastname@example.org>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850