At 12:52 PM 6/6/2002 +0200, Simon Josefsson wrote:
This means IDN is not guaranteed to be secure on non-Unicode systems.
There are alot of non-Unicode systems out there today...
1. I assume your use of "secure" does not refer to security technology,
but rather to something like correct or productive use.
2. New standards are about new capabilities. If a system does not support
the standard -- in its entirety -- then of course it cannot use the standard.
With respect to use of data formats, a system implementing a standard must
map between the network standard format and their internal format. That is
the nature of interoperability formats; it has been the approach to open
systems standards for more than 30 years and it works well.
> When standards bodies for character sets define such equivalences, and
> when those equivalences gain popularity, it might be appropriate for
> the IDN effort to consider incorporating these new standards.
This isn't an adequate solution IMHO, when the consequences of errors
made by such standard bodies, or conflicts between different standard
It appears that you want to do standards development in a different world
than the one we currently occupy. Most folks prefer to work within the
current reality.
On the plus side, the nature of the model is called divide and conquor. To
make a complex problem tractable, solve as little of it as is practical,
using an many existing component solutions as can be found.
My own belief is that the single biggest cause of failed standards efforts
is failure to constrain the initial solution effort, leading to confusion
and delay.
(The details of how to attack systems based on charset equivalence
mapping tables differences, or changes in Unicode decomposition
tables, has been discussed recently on the IDN list.)
Discussions are fine. However the only things that really matters is
specifications and their acceptance.
This issue has been under discussion for a few years.
Please point me to the detailed specification that solves the equivalence
problem.
Please point me at the base of community support for this specification.
Absent a concrete specification and community support for it, all you are
suggesting it that we wait more years in the hope of developing something
that has so far proved extremely elusive.
That's not a very good plan for getting anything useful and getting it in a
timely manner.
d/
----------
Dave Crocker <mailto:dave(_at_)tribalwise(_dot_)com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850