Subject: Re: [idn] hostname history hell

From: liana Ye <[email-masked]>
Date: Wed, 21 Nov 2001 01:21:24 -0800

These are very sensible rules, and we have 20,000+
CJK characters at hand to be resolved, and can not
affort to dive into more variations at this stage.  
However, I agree with Tim that there is a way to represent
some drawing characters in IDN, but not in DNS. 
Many Latin language users will benefit from proper 
solution of  the 20,000+ CJK problem. If you can think 
whois database as a more broader DNS database, 
instead of IDN database ( which there is yet to be a  solid 
image, or is like  "a left-wizzlepop" plus a  "left-popplewiz")
 then the what you are worring about "market research" 
may be relexed.  

Liana

> > John C Klensin wrote:
> > 
> >> It was also noted at the time that hyphen was a common
> >> argument ("qualifier") introducer in some command languages
> >> and a common introducer for negative numbers in input strings
> >> in others, and hence better avoided.
> > 
> > The argument-introducer aspect is probably still applicable.
> > Should we keep the no-leading-hyphen rule for i18n host
> > identifiers? We're not explicitly tagging -GW or -TAC
> > postfixes so that is not required (but may be desirable for
> > compatibility).
> 
> My own personal position/ bias is that we should be as
> conservative about what is permitted in an IDN as possible
> consistent with meeting the requirement for identifiers drawn
> from any of the world's languages or combinations of them.  Put
> differently, I think the general model of the old "hostname"
> rules has served us well.  I would like to think of the IDN work
> as expanding that model to include additional alphabetic and
> ideographic characters, rather than discarding the model and
> seeing how much "stuff" we can put in.
> 
> If a too-restrictive model turns out to be a mistake, it is
> possible to expand it later (just as "leading digit" was
> unblocked); if we adopt a model that turns out to be too broad,
> there is probably no way back.
> 
> On that basis, my inclination would be to:
> 
> 	* continue to prohibit leading (or trailing) hyphens
> 	
> 	* continue to prohibit all spacing characters
> 	
> 	* continue to prohibit all punctuation characters except
> 	for that hyphen and the label-separating period (full
> 	stop, ".")
> 	
> 	* prohibit, in the spirit of the hostname rules, all
> 	symbol and drawing characters
> 
> We don't _need_ them for identifiers.  Some of them will, sooner
> or later, run up against a legitimate command language or cause
> "interesting" lexical parsing problems (even if they don't cause
> problems in today's URI syntax definition).  High risks,
> marginal benefit.
> 
> Just my opinion, of course, but I have these scars...
> 
>     john
> 
>

---

From: John C Klensin <[email-masked]>
Date: Wed, 21 Nov 2001 09:30:20 -0500

--On Wednesday, 21 November, 2001 00:54 -0800 liana Ye
<[email-masked]> wrote:

Eric Hall wrote:

>> ASCII versions of these are already prohibited by nameprep. 
>> Look-alikes
>> from other ranges should be prohibited to eliminate security 
>> problems
>> which would arise from purposefully misleading domain names.
> 
> 1) Are these "Look-alikes from other ranges" going to be
> prohibited forever? Or 2) are you suggesting them to be left
> for future resolution? 

> If it is 1) then the Kanji users will be unhappy about loosing
>  codepoints from UCS.  If it is 2), then it is consistent with
> [TSconv]  authors. 

I can't speak for Eric, but my short-term goal is to let this WG
finish and emit whatever it is going to emit, consistent with
minimal risk to the DNS and the Internet (see other note).  That
suggests that we should prohibit anything of the variety I
identified now and, as needed, come back and revisit them later.
I think that is consistent with your (2).  

However, with specific regard to the Kanji users, I would
probably be willing to adopt a narrower view of "look alike"
than you may be assuming (again, can't speak for Eric).  To some
extent, we have lost the "look alike"  battle if we accept "A"
in Latin-derived, Cyrillic, and Greek scripts.  And I believe
that ambiguity can be resolved only by a search-and-match
process that has the user in the loop, e.g., the second or third
layer of the multi-layer search model.

>  then the what you are worring about "market research" 

I don't understand what point you are trying to make here.
There is a clear requirement, with which I have heard no one
disagree, that we handle CJK characters properly.  The
"picture-drawing" characters and symbols I'd like to see
excluded as an extension of the "hostname" reasoning are, e.g.,
Ux2500 - Ux27BE.  I'm also dubious about, and would like to
exclude until a clear need is demonstrated, Ux2800 through
Ux28FF.  That is not a comprehensive list -- I want to see if we
can agree on a principle, then start identifying character
blocks, rather than vice versa -- but should give you an idea.
And there aren't any Kanji in those blocks.

The whois example is only an example.   But I think your
suggestion implies that whois tables be kept, and indexed,
strictly in ACE-like form.  And no one I've talked to is willing
to accept that, partially because whois traditionally accepts
wildcards while DNS does not (cannot). An IDN-ized DNS implies
an IDN-ized Whois, as far as I can tell.

    john