Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt

[Dave Crocker <dhc@dcrocker.net>]

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