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