Subject: Re: [idn] Re: hostname history hell

From: vint cerf <[email-masked]>
Date: Tue, 20 Nov 2001 12:40:47 -0800

I think the point in 1912 was to avoid "names" that look like
IP addresses and something ending in ".com" probably would not
create a syntactic problem.

Vint

At 01:43 PM 11/20/2001 -0600, Eric A. Hall wrote:

>"Eric A. Hall" wrote:
>
>> Minimum 2 alphanumeric characters, maximum 63 alphanumeric chars,
first
>> char alphanumeric, last char alphanumeric. Maximum 255 for FQDN. FQDN
>> must contain at least one alpha.
>
>Also note that RFC 1912 (Common DNS Errors) stated that “labels may not
be
>all numbers” and even cites 411.org. and 1776.com. as domain names that
>break this rule. However, RFC 1912 is classified as informational, and
>there is no support for this tighter naming restriction in any
>standards-track documents. This is the source of some confusion.
>
>--
>Eric A. Hall
http://www.ehsco.com/
>Internet Core Protocols
http://www.oreilly.com/catalog/coreprot/

---

From: Kenneth Whistler <[email-masked]>
Date: Tue, 20 Nov 2001 17:37:19 -0800 (PST)

While we're being high-minded on this idn thread from hell...

> > Since you introduced the term "market research" into this
> > previously high-minded discussion ( :-( ), have you thought
> > about what you would put into a whois-like table with these
> > things?  How you would feel about being put into the middle of a
> > discussion of whether a name starting in a left-wizzlepop was
> > too similar to one starting in a left-popplewiz?

The left-wizzlepop has been officially encoded now at U+29D8,
with the corresponding right-wizzlepop at U+29D9. And there is,
indeed, an issue of confusion with the popplewiz, encoded at
U+299A (although it isn't clear that the popplewiz comes in
a left or a right variety, unlike the wizzlepop). See:

http://www.unicode.org/charts/draftunicode32/U32-2980.pdf 

> > I may have
> > missed something, but my impression is that the UTC TRs that
> > describe canonicalization don't do much for drawing characters:

The Unicode Technical Report in question, is UAX #15, Unicode
Normalization Forms, which describes normalization of Unicode
character sequences. ("Canonical ordering" is another thing,
which is why we avoid the term "canonicalization" for referring
to normalization of Unicode data.) But yes, Unicode normalization
does nothing for most of the symbols, including all the box
drawing characters and the like, since there are no equivalent
sequences for these things formally defined in the standard -- 
certainly not just on the basis of visual confusability.

> > do you propose that the IETF do that work?  

Now *there's* a daft thought.

--Ken

> > Or do you think it
> > is unnecessary?

---

From: [email-masked]
Date: Wed, 21 Nov 2001 13:11:12 +1100

> rfc1035 expanded the hostname rules implicitly

RFC 1035 did not change the definition of a hostname in any
way shape or form other than reducing the *effective* maximum
hostname length to 253, that being the maximum length that
can be encoded on to the wire.

The root label takes up one octet and the length of the first
label takes up one octet.  The rest of the lengths are matched
by period.

The suggested name sytax is just that *suggested* along with
instructions to check the relevent RFC's for what is legal
for a particular purpose.

Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: liana Ye <[email-masked]>
Date: Wed, 21 Nov 2001 00:54:35 -0800

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

Liana