Re: [idn] URL encoding in html page

[Dave Crocker <dhc@dcrocker.net>]

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:dave@tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850