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

[liana Ye <liana.ydisg@juno.com>]

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