This is CDNC final comments. Please respect their experties
in dealing with large character sets. Yes, it is difficult to
standardize character mapping tables, as we know well
enough. Without the mapping tables there is no IDN either.
Yes, you are right on divide and conquor. What is dividable
what is not dividable is what we have been debating on this
list.
UCS is not dividable is your position. I say it is dividable
with langage tag.
IDNA is diviable from a standarded character mapping
table is your position. I say it is undividable from the
IDNA specification.
Liana
On Thu, 06 Jun 2002 08:17:29 -0700 Dave Crocker <dhc(_at_)dcrocker(_dot_)net>
writes:
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