At 12:32 PM 6/11/2002 -0700, liana Ye wrote: >No, IDNA does not replicate the model of MIME. MIME >deals with programmer-defined data types: multi-media. >These are well defined data types, and all MIME does >is to provide multiple channels - in sequence or in >parallel to accommodate them.
MIME does several things. One of them is to permit use of extended character sets. Another is to provide a way of encoding non-ascii data onto an ascii "transport" environment. These are the parts of MIME that are relevant to IDN. The mechanisms of labeling different data types is a third MIME function, but it is not relevant to IDN. >IDNA has to consider charsets which can be an analogy >to multi-media, or I shall call them multi-charset in >term of LDH, Utf8, Utf16, GB, BIG5... IDN has chosen to use Unicode, rather than support an infinite range of alternative character sets. >IDNA has to consider UCS too, which reflexes the history IDNA is not intended as a general mechanism for supporting a wide range of historical character sets. It is intended to provide a single set of characters. >In one word, IDNA at least is two folds more complex >then MIME. IDNA is a subset of MIME capabilities, as described above. >The WG at IETF has to provide an infinitly-many solution >to deal with the two infinity problems: multi-culture and >open-glyph. Thank you. Your statement, here, underscores a fundamental difference in philosophy. When creating a standard, it is appealing to try to support a wide range of capabilities. This kind of support is flexible and it attempts to be friendly to a world of diversity. However experience shows that such flexibility often works against usefulness! Within the IETF world of standards, specifications tend to be far more successful when they LIMIT their flexibility. In particular, standards that choose a single capability, rather than supporting a wide range of alternatives, are simpler and easier to implement and simpler to use. These are very powerful benefits and they greatly increase the likelihood that a standard will succeed. > > a) making the scope of such an effort too large is a good > > way to ensure that it never gets done; however it is often easy > > to have that larger scope as a background agenda that is > > serviced along the way. > > > > b) we are some years too late for visiting that question > > upon this effort. > >This question has been looked at many times in the past, >and every time we have decided to postpone the issue. If >you say it is too late to visit this issue again, then you are >definitly repeating the past. It is certainly true, we have made >progress in understanding the problem :-) We could study the problem forever. However you might have noticed that registries are already selling proprietary IDN solutions today. If we wait longer, the proprietary solutions will lock out any opportunity for using an open standard. The market needs a standard today. In fact, it needed it several years ago. Your comments suggest a lack of urgency that I believe is very much at odds with the urgency felt by the market. d/ ---------- Dave Crocker <mailto:[EMAIL PROTECTED]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
