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

From: liana Ye <[email-masked]>
Date: Tue, 11 Jun 2002 12:32:44 -0700

John has a good separation of the issues and I'd like
to offer a different view point from yours following the topics. 

> At 10:46 AM 6/11/2002 -0400, John C Klensin wrote:
> >(1) Is IDNA properly and adequately specified for the uses to
> >which it will be put and is it designed appropriately for that
> >range of uses?
> 
> Basically, IDNA replicates the model of MIME.  If there are problems 
> with 
> it, they are in the category of the usual, initial specification 
> detail 
> bugs that will be fixed as the document moves to Draft.  I haven't 
> noticed 
> any such detail bugs being cited yet.
> 
> It does not appear that there are any problems with the model.  The 
> model 
> has been incrementally improved and strikes me as having gotten 
> quite clean 
> at this point, for the purpose it is designed to serve.

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.  

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... 

IDNA has to consider UCS too, which reflexes the history
of character sets 1) used by user groups and 2) existed for 
thousands of years and 3) no update limit can be called upon.

Assume we can define how many user groups in terms
of charset can be handled in IDNA,  IDNA still has to 
deal with two infinity problems: 

a) the long history brought to us by different groups use
  the same character set, such as Arabic, CJK, and Latin.
  I would call this multi-culture problem. 

b) USC has to stay open for more update on new glyphs to be 
 allowed into the set, this is pointing to trademark problem,
 which we at IETF are supposed to provide a feasible 
 solution for.  I call this open-glyph problem.

In one word, IDNA at least is two folds more complex 
then MIME. 

> >(2) Is IDNA closely bound to internationalization of the DNS or,
> >as you note above, is it really "about a micro layer above DNS
> >and below applications" and hence "has nothing to do with
> >putting anything into RRs"?
> 
> Is MIME closely bound to multi-media email or is it a micro-layer 
> above 
> email?
> 
> The answer is yes to both parts, rather than representing mutually 
> exclusive conditions, as the question implies.
> 
> That the general topic of internationalization is difficult and 
> multifaceted will come as no surprise to folks who work on that 
> challenging 
> arena.  That it can benefit from divide and conquer should come as 
> no 
> surprise to folks experienced with IETF work.
> 
> To repeat:  Messing with RRs, for FURTHER internationalization 
> sounds like 
> a dandy idea.  Messing with RRs as part of IDNA will only have the 
> effect 
> of adding another couple of years of delay.

So, I agree, existing RRs are well defined to handle charsets, 
there is no room to messing around with them.

> >(3) Should the applicability of IDNA in the DNS context, and the
> >xxx-prep procedures to be used with it, be specified on a per-RR
> >(and per-Class) basis?
> 
> An excellent starting question, for a separate, follow-on effort for 
> FURTHER internationalization of the DNS.

This is the question we are facing and due to be dealt 
with.  This is the essence of 
CDNC Final Comments on Last call of IDN drafts. 

The WG at IETF has to provide an infinitly-many solution 
to deal with the two infinity problems: multi-culture and 
open-glyph. 

> >(4) To what extent should out-of-band communications between
> >applications, which utilize strings which the applications might
> >construe as internationalized domain names, influence the design
> >of IDNA and, if so, what should the impact be?
> 
> I think your question nicely captures a source of confusion that is 
> currently present.
> 
> My own answer is that
> 
>          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 :-) 

Liana Ye

---

From: Dave Crocker <[email-masked]>
Date: Thu, 13 Jun 2002 15:28:52 -0700

>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.

>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

IDNA is a subset of MIME capabilities, as described above.

>to deal with the two infinity problems: multi-culture and

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.

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