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