Subject: Re: [DNSOP] I-D Action:draft-liman-tld-names-00.txt

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Mar 2009 10:48:40 +0100

On Tue, Mar 03, 2009 at 05:00:01PM -0800,
 [email-masked] <[email-masked]> wrote 
 a message of 52 lines which said:

> 	Title           : Top Level Domain Name Specification
> 	Author(s)       : L. Liman
> 	Filename        : draft-liman-tld-names-00.txt

[What is the proper email address for discussions? Let's try dnsop.]

>  tldlabel = ALPHA *61(ldh) ld

Why at least two characters? Why not:

  tldlabel = ALPHA *1(*61(ldh) ld)

There is no *technical* reason to prevent one-letter TLDs (there can
be layer-8 reasons but they are handled by section 3).

---

From: Lars-Johan Liman <[email-masked]>
Date: Wed, 04 Mar 2009 13:29:58 +0100

> [What is the proper email address for discussions? Let's try dnsop.]

[I had hoped to avoid pinpointing it to a specific working group just
yet ... It's neither a typical protocol spec, nor a server operations
issue, so it doesn't fit "naturally" in either of them.]

> be layer-8 reasons but they are handled by section 3).

You may be quite right about that. It's one of the things that I want
to have a discussion about. I started out with a somewhat conservative
specification, to see where the discussion will take us.

More voices?

				Cheers,
				  /Liman
#----------------------------------------------------------------------
# Lars-Johan Liman, M.Sc.   ! E-mail/SIP/Jabber: [email-masked]
# Senior Systems Specialist ! Tel: +46 8 - 562 860 12
# Autonomica AB, Stockholm  ! http://www.autonomica.se/
#----------------------------------------------------------------------

---

From: "Alexander Mayrhofer" <[email-masked]>
Date: Wed, 4 Mar 2009 14:56:35 +0100

> specification, to see where the discussion will take us.

I would keep the ABNF to purely *technical* limits as well. Don't let
the ABNF preclude any policy decisions.

Alex

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 4 Mar 2009 15:13:57 +0100

On Wed, Mar 04, 2009 at 02:56:35PM +0100,
 Alexander Mayrhofer <[email-masked]> wrote 

> the ABNF preclude any policy decisions.

+1 

But this criteria is easier written than applied. For instance, should
the ABNF allow fully-numeric top-level domain names? There is no
*technical* reason to ban them. 

With IPv4, RFC 1123 section 2.1 clearly says "The host SHOULD check
the string syntactically for a dotted-decimal number before looking it
up in the Domain Name System" so 1.2.3.112 is unambiguously the
machine of IP address 1.2.3.112 even if the TLD ".112" is
delegated. (With IPv6, it is even clearer since applications typically
require some form of indication that it is an IP address, see RFC 3986
section 3.2.2).
 
[In case you wonder, yes, I'm for allowing fully-numeric TLD, _in that
I-D_, section 3 still being applicable.]

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 4 Mar 2009 11:55:39 -0500

> *technical* reason to ban them. 

There's a strong technical reason to ban any numeric TLD name that
could be interpreted as part of a dotted-quad, however, and for the
sake of technical simplicity it might in fact be much easier just to
ban them all instead.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 4 Mar 2009 12:24:46 -0500

>*technical* reason to ban them.

There is one.

I am not the best person to describe the entire problem but I'll give it a try.

When it come to IDNs there is a case of "BiDi" (bidirectional) characters.

Some characters have encoded in them the 
placement of the next character, to the right or 
left.  These characters are strong.  Other 
characters do not have this information, they are 
weak.

Numbers and punctuation are weak.  Other symbols 
(it's not accurate to call them letters) are 
strong (not exclusively).  Because you might mix 
numbers and digits in a domain name (www.163.com) 
the weak characters will inherit the directional 
information of the other characters.

For the raw data I learned this from, look at these links:

http://stupid.domain.name/node/681
http://stupid.domain.name/node/682
http://stupid.domain.name/node/683

And the only confirmation I have that I'm "on to 
something" is this in private correspondence with 
the Patrik.  I include his comments because I am 
still not competent on this subject.

At 1:55 +0100 12/2/08, Patrik Fältström wrote:
#On 1 dec 2008, at 22.06, Edward Lewis wrote:
#
#> So, when pressed to explain this to someone, is this more or less accurate?:
#>
#> With IDNs and specifically bidirectional text (referring to left to right
#> reading languages like Arabic), the direction in which the characters are
#> to be rendered ("is this one to the right or the left of the previous") is
#> sometimes stored in the data of the character itself.
#
# I would say "...is dependent on the directionality properties of the
# character".
#
#> Characters with this data are "strong" and those without are "weak."
#
#"..with explicit directionality data are..."
#
#> Because of the special role of punctuation and 
of digits, they are both weak.
#
# "...both weak which implies the order depends among other things on the
# overall directionality of the text."
#
#> Because a dot and a digit are weak, there's no way to guarantee that
#> ".1" will never be seen as "1." in a domain name.  There is a way to
#> guarantee it if you include directional aids, but this is apparently not
#> done where domain names appear.
#
#Correct.

>I-D_, section 3 still being applicable.]

Curious - still?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Never confuse activity with progress.  Activity pays more.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 05 Mar 2009 10:23:33 +1100

> sake of technical simplicity it might in fact be much easier just to

	3735928559 is also a IPv4 address.
	222.11386607 is also a IPv4 address.
	0xdeadbeef is also a IPv4 address.
	0xde.0xadbeef is also a IPv4 address.
	0xde.0xad.0xbeef is also a IPv4 address.
	0xde.0xad.0xbe.0xef is also a IPv4 address.

	Banning tlds that start with a digit is the simplest most
	straight forward way to stop confusion.  I know of no IPv4
	address format that starts with a letter.

	IPv6 address presentation forms have colons in them so they
	are not going to collide with hostnames.
 
	Mark
> A
> 
> 
> -- 
> Andrew Sullivan
> [email-masked]
> Shinkuro, Inc.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 6 Mar 2009 10:56:45 +0100

On Wed, Mar 04, 2009 at 11:55:39AM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 22 lines which said:

> could be interpreted as part of a dotted-quad, 

They cannot be "interpreted as part of a dotted-quad" if everyone
follows RFC 1123 section 2.1 "The host SHOULD check the string
syntactically for a dotted-decimal number before looking it up in the
Domain Name System".

---

From: Mark Andrews <[email-masked]>
Date: Sat, 07 Mar 2009 01:32:57 +1100

> syntactically for a dotted-decimal number before looking it up in the

	If I put this record into the DNS "1.2.3.4. A 4.3.2.1"
	and email to [email-masked].  Where does the email go?

	Next I telnet to 1.2.3.4 port 25.  Where does that connection
	go?

	If 1.2.3.4 is a legal hostname / mail domain then the first will
	go to 4.3.2.1 port 25 and the second to 1.2.3.4 port 25.

	To send email to a IP address I need to use "user@[1.2.3.4]".
	The MTA knows 1.2.3.4 is a hostname not a IP address.

	Put 1.2.3.4 into the rdata of a MX/SRV record.  Similar
	problem at the client knows these are name and not addresses.

	Mark

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Mar 2009 14:08:55 -0500

> syntactically for a dotted-decimal number before looking it up in the

Funny you should say that, because RFC 1123 section 2.1 _also_ says,
"However, a valid host name can never have the dotted-decimal form
#.#.#.#, since at least the highest-level component label will be
alphabetic."  Therefore, I think appealing to the RFC 1123 rules for
this case is going to be tricky.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Mar 2009 14:38:37 -0500

At 14:08 -0500 3/6/09, someone wrote:

>...I think appealing to the RFC 1123 rules for this case is going to 
>be tricky.

Remember that RFC 1123 was written in a historical epoch much 
different than today.  No IDNs.  No URLs.  No thought of domain names 
in newspapers.

The BiDi issue will pretty much prevent us from seeing a TLD 
beginning or ending with a digit in the global public Internet root 
zone.  Even if the whole issue is too new to be in an RFC (IETF's 
IDNABIS WG might get around to one).

Getting everything you want is easy, if you don't want much.

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Mar 2009 15:13:47 -0500

On Fri, Mar 06, 2009 at 02:38:37PM -0500, Edward Lewis wrote:

> Remember that RFC 1123 was written in a historical epoch much different 
> than today.  No IDNs.  No URLs.  No thought of domain names in 
> newspapers.

But depending on whether you think the text I quoted is normative,
1123 may actually forbid those IDNs at the top level.  Which would be
a bad thing, I think.

> The BiDi issue will pretty much prevent us from seeing a TLD beginning or 
> ending with a digit in the global public Internet root zone.  Even if the 
> whole issue is too new to be in an RFC (IETF's IDNABIS WG might get 
> around to one).

Surely not.  The BiDi issue may prevent anyone from seeing a U-label
beginning or ending with a digit from being "added" to the root.  What
actually gets added to the root zone, however, is an A-label.  It
makes no difference whether that A-label begins or ends with a digit
(it won't begin, I predict, but I'm not sure whether it might end with
one), since A-labels are always ASCII. 

Or are you saying that display issues coming from ASCII-only labels in
a BiDi display context need to govern the contents of zone files.  If
so, I think that really really needs to get raised in idnabis soon.
That's not my understanding of the issue so far.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Edward Lewis <[email-masked]>
Date: Fri, 6 Mar 2009 15:54:58 -0500

>1123 may actually forbid those IDNs at the top level.  Which would be

I'm not sure what...a bad thing would be forbidding IDNs or is a bad 
thing removing the prohibition on IDNs...anyway.  I think that 
there's going to be some room to question the old texts due to new 
requirements.

While we can't always upend the installed base because we want to 
expand the capabilities, sometimes it's the way the rules were 
written that is the issue.

>That's not my understanding of the issue so far.

I"ll preface my response by saying - I'm not all that confident in my 
knowledge of IDNs and the BiDi issue.  But when I talked with some 
folks around the ICANN circus, there was conventional wisdom that 
there would be no admission of a delegation beginning or ending with 
a digit to the root zone.  This bar was in place because of the BiDi 
issues as I understand from Patrik Faltstrom's blog.

And, from what I have heard, I believe "display issues" is at the 
heart of the problem.

I'm sure Patrik is active in the IDNABIS WG.  So if it is an issue, 
he'd have spoken about it.

Still, seriously, all this aside, I doubt we will ever want 
"manpages.5" as a domain name.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 6 Mar 2009 16:11:11 -0500

On Fri, Mar 06, 2009 at 03:54:58PM -0500, Edward Lewis wrote:

> knowledge of IDNs and the BiDi issue.  But when I talked with some folks 
> around the ICANN circus, there was conventional wisdom that there would 
> be no admission of a delegation beginning or ending with a digit to the 
> root zone.  This bar was in place because of the BiDi issues as I 
> understand from Patrik Faltstrom's blog.
>
> And, from what I have heard, I believe "display issues" is at the heart 
> of the problem.

Ok, so the "no beginning or ending digit" rule is a rule about
U-labels, and not necessarily about A-labels.  So the outstanding
question, relevant to the draft at hand, is whether the issue is
important for A-labels as well.

Since this has been a topic of some importance in IDNAbis, I'll ask
the people over there about it.  Patrik is not the only person in that
community who's on top of this issue.

[Aside: while I'm on the topic of IDNAbis, I've recently again been
reminded that it'd be really, really good if people with DNS clue
would have a look at that work to see if there's anything
problematic.]

> Still, seriously, all this aside, I doubt we will ever want "manpages.5" 
> as a domain name.

But I have no difficulty imagining someone with more money than sense
wanting .666 as a TLD.  And with the latest ICANN policies, they'd have
a stronger argument than they once did.  The question is whether there
are important technical reasons to say no.  "666" could never appear
as part of an IPv4 address, after all.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 07 Mar 2009 00:00:41 +0100

I haven't read the draft yet, but the discussion whether numeric
labels are allowed seems to get slightly out of hand.

Anybody can use them and apparently people are. That is easily
proved but running something like:

	for i in `seq 1 1 1000`; do echo $i; dig +short $i.com; done

and replace .com with different TLDs such as .info, .biz, .pro,
.cn, .nl etc. as well.  (Variations in the boundaries is also
advised so you can stumble on 4711 and similar trademarks).

Whatever the scriptures are saying or how they can be interpreted,
I haven't seen seen the network crashing down due to this practice.

That using multiple numeric domains can backfire and that if you
open a web-shop at the host named 127.0.0.1 might not result in a
stellar sized customer base is something completely different. You
just get what you ask for.

	jaap

---

From: Mark Andrews <[email-masked]>
Date: Sat, 07 Mar 2009 10:42:57 +1100

> as part of an IPv4 address, after all.

	1.666 is a valid IP address.

drugs:9.7.x 10:41 {322} % telnet 1.666
Trying 1.0.2.154...
^C
drugs:9.7.x 10:42 {323} %

---

From: SM <[email-masked]>
Date: Fri, 06 Mar 2009 22:58:58 -0800

The topic discussed in draft-liman-tld-names-00 has two angles, the 
application angle and the DNS angle.  The "requirements" can be 
different depending on which angle we are looking at.  From Section 
11 of RFC 2181:

   "The DNS itself places only one restriction on the particular labels
    that can be used to identify resource records.  That one restriction
    relates to the length of the label and the full name.  The length of
    any one label is limited to between 1 and 63 octets.  A full domain
    name is limited to 255 octets (including the separators).  The zero
    length full name is defined as representing the root of the DNS tree,
    and is typically written and displayed as ".".  Those restrictions
    aside, any binary string whatever can be used as the label of any
    resource record."

   "Note however, that the various applications that make use of DNS data
    can have restrictions imposed on what particular values are
    acceptable in their environment."

   "Clients of the DNS can impose whatever restrictions are appropriate
    to their circumstances on the values they use as keys for DNS lookup
    requests, and on the values returned by the DNS.  If the client has
    such restrictions, it is solely responsible for validating the data
    from the DNS to ensure that it conforms before it makes any use of
    that data."

The title of the document is "Top Level Domain Name 
Specification".  If it is about gTLDs, some may see this as a matter 
for some other organization instead of the IETF.  Section 4 of the 
draft requests IANA to change its registration process to use the 
specification.  Is the registration process set by the IETF or an 
other organization?

There are some clarifications about the syntax of an Internet host 
name in Section 2 of RFC 1123.  The "Discussion" part of that section mentions:

   "However, a valid host name can never have the dotted-decimal
    form #.#.#.#, since at least the highest-level component label
    will be alphabetic."

According to Section 2 of draft-liman-tld-names-00, the top level 
domain label can be numeric only.  This can lead to confusion if we 
cannot determine whether the string is a FQDN or an IP address.

 From Section 2.1 of RFC 1912 (Informational):

   "You should also be careful to not have addresses which are valid
    alternate syntaxes to the inet_ntoa() library call.  For example 0xe
    is a valid name, but if you were to type "telnet 0xe", it would try
    to connect to IP address 0.0.0.14.  It is also rumored that there
    exists some broken inet_ntoa() routines that treat an address like
    x400 as an IP address."

The word "whether" is not spelled correctly in Section of the draft.

There is ongoing work in the IDNAbis Working Group on 
IDNA.  draft-ietf-idnabis-protocol-10 proposes to obsolete RFC 3490.

Regards,
-sm

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 12:07:01 +0100

> he'd have spoken about it.

Yes, active there, following this list.

> "manpages.5" as a domain name.

I think regarding digits in TLDs (or rather, non-letters), this is the  
right time when one definitely should have the basic rule to not "add  
something until it breaks", but instead, "only add things we do know  
will not create any harm". And I think within those basic rules, we  
should just say no to digits in TLDs. Anywhere. Or rather, every  
character in a U-label in a TLD have to have an explicit directionality.

I think it is time to not have a general rule "lets add something if  
not proven that adding will create harm", but instead "lets add  
something only if proven that it absolutely not does create any harm",  
and then have the people that want certain dangerous characters in  
there explain why it is safe.

    Patrik

---

From: [email-masked]
Date: Sat, 7 Mar 2009 13:56:12 +0000

does this mean my chances for  ^B. are nil?  :)

--bill

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 15:13:44 +0100

> does this mean my chances for  ^B. are nil?  :)

Go for it!

But I think foo^H^H^Hbar is more interesting as a label. Maybe with a  
^G in there as well.

    Patrik

---

From: [email-masked]
Date: Sat, 7 Mar 2009 14:31:40 +0000

na... the ^B.  is for the visually impared.  the DNS can talk!
 (and it does meet your "explict directionality" concern.)

 actually, I have a fundamental disagreement w/ your logic.  I think
 that your general rule of "only add if proven to create no harm" or
 infering "dangerous" - are on the slippery slope of stifling inovation.
 IDN's by their very nature are proven to create harm... yet we are 
 doing them :)

 i think the better rule is, add something if it creates value.

--bill

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 15:38:58 +0100

> (and it does meet your "explict directionality" concern.)

If you with ^B talk about U+0002, then it does not fulfil the explicit  
directionality requirements as it is BN, Boundary_Neutral.

   Patrik

---

From: Andrew Sullivan <[email-masked]>
Date: Sat, 7 Mar 2009 10:01:30 -0500

On Fri, Mar 06, 2009 at 10:58:58PM -0800, SM wrote:

> The title of the document is "Top Level Domain Name Specification".  If 
> it is about gTLDs, some may see this as a matter for some other 
> organization instead of the IETF.  Section 4 of the draft requests IANA 
> to change its registration process to use the specification.  Is the 
> registration process set by the IETF or an other organization?

I'm not sure I understand the worry here: the document reads perfectly
clearly, to my eyes, that other organizations may have something to
say about actual TLDs; the draft is only about the _technical_
specification of what may be in the TLD.  

> According to Section 2 of draft-liman-tld-names-00, the top level domain 
> label can be numeric only.  

No: 'and it MUST start with an ASCII "letter"'.  Therefore, it can't
be numeric only.  In another thread I've been playing devil's
advocate, attempting to see if there is any argument for weakening
that position.  So far, none, I'm delighted to say.

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Mar 2009 05:25:12 -1000

Patrik,

On Mar 7, 2009, at 1:07 AM, Patrik Fältström wrote:
> something only if proven that it absolutely not does create any  
> harm", and then have the people that want certain dangerous  
> characters in there explain why it is safe.

Define "harm".

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 16:33:01 +0100

On 7 mar 2009, at 16.25, David Conrad wrote:

>> I think it is time to not have a general rule "lets add something  
>> if not proven that adding will create harm", but instead "lets add  

I want it the other way around. I want someone to define "no harm".

Examples might be things like inability for the owners of 2nd level  
domains to enter the domain name they registered in browsers, problems  
to use the domain name (including the TLD) in text, or whatever. I.e.  
it to some degree have to do with what policy you have for  
registrations in the 2nd level domain (for rendering purposes for  
example).

On top of this, I would like to have a situation where if someone  
complains after you got your domain, it is your fault, not a problem  
for an evaluation/assignment committee that did some evaluation (or  
not).

If you want a TLD, you tell me that you will not create any harm. You  
do, you get the domain, things go poof, then you did not do your  
homework beforehand.

    Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 16:35:49 +0100

> Define "harm".

Here is a link to one of the blog pages of mine that show in a  
filesystem what I think is "harm" if we allow mix of codepoints etc  
that give same result(s) for domain names.

I claim that is "harm".

    Patrik

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 07 Mar 2009 17:28:59 +0100

Go for it!

I claim ^S

	jaap

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Mar 2009 07:14:40 -1000

Patrik,

On Mar 7, 2009, at 5:33 AM, Patrik Fältström wrote:
> If you want a TLD, you tell me that you will not create any harm.  
> You do, you get the domain, things go poof, then you did not do your  
> homework beforehand.

So, just to be clear, you would disallow new top-level domains unless  
you can prove a negative?  :-)

Regards,
-drc

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 7 Mar 2009 10:19:54 -0800

At 12:07 PM +0100 3/7/09, Patrik Fältström wrote:
>I think regarding digits in TLDs (or rather, non-letters), this is the right time when one definitely should have the basic rule to not "add something until it breaks", but instead, "only add things we do know will not create any harm".

Yes, that's a good statement.

>And I think within those basic rules, we should just say no to digits in TLDs. Anywhere. Or rather, every character in a U-label in a TLD have to have an explicit directionality.
 
I'm not sure I agree that we should go that far. It is clear that TLDs should not start with digits because of bad BiDi interactions.

I thought that a TLD of "E164" (to take a controversial example...) is known to cause no harm at a TLD due to BiDi issues, but I could be wrong. All labels will be to the left of it. There is a LtoR character at the beginning. Is there a legal U-label that can go before it that will cause the "E" or any digits to move?

I have no idea about, for example, "<RtoLcharacter>164" as a TLD.

>I think it is time to not have a general rule "lets add something if not proven that adding will create harm", but instead "lets add something only if proven that it absolutely not does create any harm", and then have the people that want certain dangerous characters in there explain why it is safe.

I'm with Patrik on this one: you have to prove the negative in order to register a TLD.

--Paul Hoffman, Director
--VPN Consortium

---

From: SM <[email-masked]>
Date: Sat, 07 Mar 2009 10:21:21 -0800

>specification of what may be in the TLD.

I don't have any concern as long as the draft is clearly read as 
being about a technical specification and that it is understood that 
other organizations might have something to say about actual TLDs.

>that position.  So far, none, I'm delighted to say.

I'm glad to see that we won't have to go through a long discussion 
about numeric host names for this draft. :-)

Are the words "name" and "label" used interchangeably in this draft?

Regards,
-sm

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 19:40:46 +0100

On 7 mar 2009, at 18.14, David Conrad wrote:

>> You do, you get the domain, things go poof, then you did not do  
>> your homework beforehand.
>
> So, just to be clear, you would disallow new top-level domains  
> unless you can prove a negative?  :-)

I guess so... :-)

The problem with writing exact objective rules is that with the 6000  
languages, and enormous number of codepoints, it is extremely hard to  
create say a regular expression that we know is _absolutely_ correct  
regarding separating the good TLDs from the bad ones.

I.e. I think we first of all have to accept there is a gray area, and  
whether a TLD label in that area is safe or not very much will depend  
on the context it is used. One of the important contexts is of course  
the 2nd level domain which is defined by the policy for that domain.

Without knowing the policy for the 2nd level domain, I think it is  
very hard to say whether a given TLD level is safe or not. Yes, I  
agree that "if a TLD label is beginning with letter" is pretty ok, but  
it is safer to say "do not start or end with a digit" (as we do not  
know whether the labels are written in a left to right or right to  
left context). Will there also be a problem with digits within a  
label? "Probably not", but I rather see a generic good definition of  
"the gray area" and who is responsible for arguing (I an not saying  
proving here) whether something is "ok to delegate" or not, and I  
think it should be the applicant that argue it is ok. Not the other  
way around.

    Patrik

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Mar 2009 10:04:30 -1000

Patrik,

On Mar 7, 2009, at 8:40 AM, Patrik Fältström wrote:
> languages, and enormous number of codepoints, it is extremely hard  
> to create say a regular expression that we know is _absolutely_  
> correct regarding separating the good TLDs from the bad ones.

Agreed.

> very hard to say whether a given TLD level is safe or not.

Unfortunately, as you're aware, policy at the second level varies over  
time and there are few (if any) limitations placed upon the evolution  
of that policy.  Attempts by ICANN to constrain 2nd level policy would  
unlikely be a bit ... challenging (particularly in the ccTLD space).

> Yes, I agree that "if a TLD label is beginning with letter" is  
> pretty ok, but it is safer to say "do not start or end with a  
> digit" (as we do not know whether the labels are written in a left  
> to right or right to left context). Will there also be a problem  
> with digits within a label? "Probably not", but I rather see a  
> generic good definition of "the gray area" and who is responsible  
> for arguing (I an not saying proving here) whether something is "ok  
> to delegate" or not, and I think it should be the applicant that  
> argue it is ok. Not the other way around.

As far as I can tell, such arguments would be subjective.  The  
applicant will obviously have an incentive to argue "of course it  
isn't going to cause any problems" which puts the burden back on ICANN  
to figure out if the applicant is being exhaustive in examining all  
possible implications of the proposed label. Not sure how much that  
helps...

Regards,
-drc

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 7 Mar 2009 21:12:38 +0100

On 7 mar 2009, at 21.04, David Conrad wrote:

>> The problem with writing exact objective rules is that with the  
>> 6000 languages, and enormous number of codepoints, it is extremely  
>> hard to create say a regular expression that we know is  
>> _absolutely_ correct regarding separating the good TLDs from the  
>> bad ones.
>
> Agreed.
>
> Unfortunately, as you're aware, policy at the second level varies  
> over time and there are few (if any) limitations placed upon the  
> evolution of that policy.  Attempts by ICANN to constrain 2nd level  
> policy would unlikely be a bit ... challenging (particularly in the  
> ccTLD space).

True...so, and to clarify my earlier statement. I think personally it  
is absolutely safe to allow TLDs that consists of codepoints that have  
a so called strong directionality. If the directionality is the same.  
This will definitely allow both RTL and LTR labels.

Now we can from this add more things, for example, talk about whether  
other codepoints (like digits) can be part of the label, etc.

But we should be careful, very careful. It is hard to undo such a  
decision as we all know. And remember that a domain name can exist in  
various contexts, including of course the ones where there is text  
"after" the TLD (if you look in logical order), and we might have any  
text there, like a digit, different directionality etc.

    Patrik

---

From: Peter Koch <[email-masked]>
Date: Sat, 07 Mar 2009 23:48:41 +0100

> different depending on which angle we are looking at.  From Section 

I'd like to support this distinction and would suggest we keep in mind the
important IDNAbis issues, but also look at the original text in RFC 1123

>     form #.#.#.#, since at least the highest-level component label

This is probably the ambiguity that draft-liman-tld-names-00 mentions.
"will be alphabetic" would not only exclude digits in the TLD, let alone
"numeric TLDs", but also IDN TLDs in the first place, since "alphabetic"
might not include the "-" character.
It is also unclear to me whether this text was meant (or, probably more
importantly: was subsequently read) as  descriptive or normative
and the lack of 'normative language' doesn't help because we're in
pre-2026 times.

> cannot determine whether the string is a FQDN or an IP address.

The draft says:

! A TLD label] MUST consist of only ASCII characters from the groups
! "letters" (A-Z), "digits" (0-9) and "hyphen" (-), and it MUST start
! with an ASCII "letter", and it MUST NOT end with a "hyphen".  

This would clearly suggest against 'numeric' TLD labels.  However, it
also opens the question why the relaxation of the first character wouldn't
apply to the TLD itself.

>     exists some broken inet_ntoa() routines that treat an address like

This is a known effect and something that truly belongs into any caveats
like section.  Unless this behavior (or other creative forms of writing
an IPv4 address) is specified in any kind of standard, it's probably
more an issue of the user interface.

{ceterum censeo, 1912 needs an update ...}

{quoted text moved down here:}
> specification.  Is the registration process set by the IETF or an 

It's a version -00 draft, so this needs more thought and discussion.
My personal opinion is that the request goes to the "wrong IANA", since
the IANA considerations section is bound by RFC 2860.  There might be
other ways to achieve the same goal, if and when the draft becomes
a technical clarification within the DNS (as opposed to IDN).

-Peter

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 08 Mar 2009 03:25:03 +0100

--On lördag, lördag 7 mar 2009 10.04.30 -1000 David Conrad
<[email-masked]> wrote:

> time and there are few (if any) limitations placed upon the evolution of
> that policy.  Attempts by ICANN to constrain 2nd level policy would

Does not ISO3166 solve that problem for us with regards to allowed
characters in the TLD label? 

-- 
Måns Nilsson			M A C H I N A

Tex SEX!  The HOME of WHEELS!  The dripping of COFFEE!!  Take me to
Minnesota but don't EMBARRASS me!!

---

From: David Conrad <[email-masked]>
Date: Sat, 7 Mar 2009 16:32:07 -1000

> characters in the TLD label?

Nope.  ISO-3166 merely defines the list IANA uses when an entity on  
the ISO-3166 list requests the delegation of a top-level domain.  
ISO-3166 is irrelevant to non-ccTLDs (including gTLDs, sTLDs, and  
{g,s,cc}IDN TLDs).

Regards,
-drc

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 08 Mar 2009 04:57:22 +0100

--On lördag, lördag 7 mar 2009 16.32.07 -1000 David Conrad
<[email-masked]> wrote:

> Nope.  ISO-3166 merely defines the list IANA uses when an entity on the
> ISO-3166 list requests the delegation of a top-level domain. ISO-3166 is
> irrelevant to non-ccTLDs (including gTLDs, sTLDs, and {g,s,cc}IDN TLDs).

And as usual my post made perfect sense until I had pressed send.. 

I mean, that for the (previously alleged to be more "interesting wrt IDN")
ccTLD part of the name space, ISO 3166, with its (at least actual if not
formal) limitation to two characters from A-Z, should "fix" the issue of
IDNA in TLD labels, leaving the gTLDs to break... 

Don't hit me!!  I'm in the Twilight Zone!!!

---

From: SM <[email-masked]>
Date: Sun, 08 Mar 2009 00:14:29 -0800

>that prompted Liman's suggestion:

This is an opportunity to look at Section 2.1 of RFC 1123 as the 
distinction is unclear within the IETF community and in other communities.

>might not include the "-" character.

Relaxing or clarifying the ambiguity of the "alphabetic rule" takes 
us into the "do no harm" arena.  That "rule" allows us to sidestep 
some possible issues if we are looking at ASCII-only TLDs only.

>and the lack of 'normative language' doesn't help because we're in

Agreed.  The text provides an explanation of the "requirements 
text".  If we want to be conservative, we can read it as clarifying 
the intent when that specification was written, i.e. "we can avoid 
the problem altogether by doing this".

>also opens the question why the relaxation of the first character wouldn't

If we remove the alphabetic constraint on the first character, we 
then have to list the exceptions (e.g. 0xe) or craft rules to cover them.

>more an issue of the user interface.

As the issue affects application-layer protocols, it would be better 
to address it as part of some 1123 or 1123-related effort.

>{ceterum censeo, 1912 needs an update ...}

Agreed.  That entails a text rewrite or some creativity as it is 
pre-2026 material.

>a technical clarification within the DNS (as opposed to IDN).

The guidelines for the IANA considerations Section is covered in RFC 
5226.  I share your opinion that the IANA considerations in the draft 
may fit under RFC 2860.  As this is a version -00 draft, the question 
could be left open for now.

Regards,
-sm

---

From: Jim Reid <[email-masked]>
Date: Sun, 8 Mar 2009 08:39:13 +0000

> IDNA in TLD labels, leaving the gTLDs to break...

If only it could be that simple. There already are some IDN labels in  
the root for test purposes: .xn--zckzah for instance is the Katakana  
for "test" (テスト). For ccTLDs the direction that ICANN appears to  
be heading probably means IDN labels for each country representing the  
name of that country in the languages/scripts used there. The ISO 3166  
list won't matter in that context. A government or ccTLD is likely to  
go to ICANN and say "Here are the IDN strings that represent our  
country name in our national languages/scripts. Put them in the  
root."  What happens for the existing gTLDs and sTLDs is anyone's  
guess....

ICANN is looking to the IETF to come up with a deterministic way of  
checking these IDN labels and provide confirmation that they don't do  
any damage: like break the installed base or somehow destabilise the  
DNS. Once the IETF has devised this process, ICANN will apply it to  
any of the zillions of new TLDs they want to create.

I'm with Patrik on this one: those proposing new TLD labels should be  
required to prove that they do no harm. However that's impractical  
because it means proving a negative. [OTOH it would be a very  
effective brake on the TLD free-for-all that ICANN seems to want.]  
This approach is unlikely to be acceptable to ICANN. They'd like to  
have a deterministic (automated?) method to validate applications for  
new TLDs.

A possible compromise solution might be to come up with an algorithm  
which filters out the obviously broken or dangerous TLD labels.  
Assuming such a thing can be devised of course.... Then if a proposed  
label passes that threshold, it goes out for wider consultation to  
allow the world to object on technical grounds that the introduction  
of the new TLD would break something. Which begs the question: what  
happens when operational problems arise after the new TLD is introduced?

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sun, 08 Mar 2009 10:59:16 +0100

No. The alpha-2 used for ccTLD labels (and also the alpha-3) codes
are restricted to the set A-Z.

	jaap

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 08 Mar 2009 16:04:51 +0100

> are restricted to the set A-Z.

...so for those there will be no problems. 

I have since been kindly informed by Patrik that while the original ISO
3166 codes are "safe", there, as Jim also wrote, will be a lot of new top
level domains. In IDN. I would agree with Patrik and Jim, that these need
to prove themselves safe, FSVO safe, first. 

/Måns, clue finally beaten in. 
-- 
Måns Nilsson			M A C H I N A

Yow!

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 8 Mar 2009 11:30:02 -0400

> regarding separating the good TLDs from the bad ones.

I'm not sure the "good TLDs from the bad ones" is what the I-D in
question is trying to separate.  I have the impression, from reading
it, that the I-D is trying to talk about the narrow, technical
definition of the last label aside from the null-length root one, as
it appears in the DNS -- what we call "TLDs", but only in the narrow,
technical sense of "the label appearing in the DNS protocol".  The
document has nothing to say about languages, code points, good policy,
&c -- it's very careful, in fact, to say that it's not tackling that
question, and is only interested in the DNS definition of labels at a
particular level.

I appreciate that perhaps the other questions are important ones that
need tackling.  But we have a narrow, technical problem right now that
needs to be addressed: at the moment, depending on how one reads RFC
1123, the IANA-operated root zone has in it labels that it should not,
because it contains labels that are not "alphabetic".  I would like to
suggest that we need to solve that specific issue first, just so that
we even have something else to talk about.  If we can't solve that
issue, then one might reasonably argue that the current IANA-operated
root zone is in violation of RFC 1123, and try to prevent additional
movement on internationalized TLDs that way.

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Florian Weimer <[email-masked]>
Date: Sun, 08 Mar 2009 19:16:51 +0100

> http://stupid.domain.name/node/681

[Bidi rendering alters the hierarchy expressed in a path name.]

> I claim that is "harm".

It's an unfortunate result of the bidi rules, I agree.  But even
without that, it can be difficult to spot the domain part of a Unicode
URL:

  <http://例え.テスト/メインページ>

But I agree that it's more significant with bidi URLs:

  <http://בײַשפּיל.טעסט/הויפּט_זײַט>

(Iceweasel shows the TLD at the end of the URL, but still
left-justifies it.)

It's possible to fix this for the browser by reconsidering how the URL
is displayed (straightforward left-justification is not that great
even for ASCII, after all).  As a result, the ordinary, in-print
rendering would differ quite significantly from the visual end result.
This isn't a problem as long as it's clear to a read of the printed
representation how to enter it in the browser.  I'm not familiar with
any right-to-left language, so I haven't got an answer to that.

---

From: Matt Larson <[email-masked]>
Date: Wed, 11 Mar 2009 10:08:04 -0400

On Sat, 07 Mar 2009, Patrik Fltstrm wrote:
> Will there also be a problem with digits within a label? "Probably
> not", but I rather see a generic good definition of "the gray area"
> and who is responsible for arguing (I an not saying proving here)
> whether something is "ok to delegate" or not, and I think it should
> be the applicant that argue it is ok. Not the other way around.

Patrik, are you suggesting that a TLD label with interior digits (but
not beginning or ending the TLD label) should be disallowed?

Or are you suggesting that anyone proposing a such a TLD with an
interior digit should prove no harm?

Or something else?

Could someone please give a concrete example of why a digit within a
TLD label would be a problem?  I grudgingly accept that the idea of
digits starting or ending a TLD label needs further discussion, but I
cannot be convinced about a prohibition against digits within a TLD
label without some justification.

Matt

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 11 Mar 2009 15:52:08 +0100

> label without some justification.

I think, with my compared to some people limited knowledge about  
Unicode, think that IF the first and last character of a TLD do have  
what is called strong, and the same, directionality, then it does NOT  
matter what is _inside_ the label.

Note that I am not using terminology like "digit" or "alphabetic" now,  
and that is intentional. I am just looking at the characteristics of  
the Unicode codepoints.

    Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 11 Mar 2009 13:13:20 -0400

[email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>
> 	Pages           : 9
> 	Date            : 2009-03-03
> RFC 1123 is ambiguous regarding the specification for top level
> domain (TLD) labels used in the domain name system.  This document
> clarifies the specification, and aligns it with current praxis,
> including the use of Internationalized Domain Name (IDN) Labels in
> TLD names.
>   
Lars-Johan,

Updating 1123, and 1122, is a good idea, and a lot of work went into 
them, not just by the editor, Bob Braden, but by dozens of people. So my 
first comment is a meta-comment to the effect that 1123 is not 
"ambiguous regarding the specification for top level domain (TLD) labels 
used in the domain name system". We didn't attempt to rigorously specify 
rlogin, telnet, ftp, smtp, or the dns, see the language in section 7 
"This section lists the primary references with which every implementer 
must be thoroughly familiar", the absence of "this obsoletes" language, 
and the stated purpose -- "incorporates by reference, amends, corrects, 
and supplements the primary protocol standards documents relating to 
hosts". What we attempted was to make some corrections, known to some of 
us, circa 1989. We did not exhaust the space of possible ambiguities in 
existing specifications, though none known were omitted to my knowledge 
by intent (and I don't have notes from that period anyway, so this is 
all personal memory), nor did we consider the possibility that the dns 
would ever cease to be policied by some public trust body, or that names 
would become trademarks (though we were all fond of memorable landmarks 
like sri-arpa), and many other fine, and not so fine things that would 
emerge in the next 20 years.

So either the text in section 2.1 of 1123 is low hanging fruit which is 
opportunistically picked in the momentary context of the third round of 
new gTLD activities by the Current New Entity (ICANN), or 1123 is 
perfect except for this one little bit which needs a little bit of 
editorial review and as a mater of convenience, is intended to be 
published as a separate RFC rather than as a revised version of 1123.

Restated more briefly, I suggest that rather than assert 1123 is 
ambiguous and you're going to fix it, a technically neutral act, you 
simply state what it is you're advocating, possibly in a disinterested 
fashion.

Next, it is a convention, which Donald, Bill, and I observed in 2929, 
that "[t]ext labels can, in fact, include any octet value including zero 
octets but most current uses involve only [US-ASCII]." The nuances I 
recall that Donald and I exchanged notes over during the drafting was 
that labels could indeed be one octet, or more, and could be any value, 
though the practice at the time was the printable range of 7-bit ASCII, 
and the LDH subset of that range. So the statement in your section 2 
would be that you'd like to assert a policy for a registry, the IANA 
root as it happens, and there's nothing wrong with writing registry 
policy, its something of a cottage industry in the ICANN g- and 
cc-playpens, but it isn't a protocol specification.

So you'd like two (or more) ASCII alphas, which the iso3166-1 MA may be 
comforted by, with the possibility of an infix digit or hyphen or 
sequence of infix digits (but not a sequence of infix hyphens) as the 
number of octets in the label increases to three or more.

That's fine registry policy. As reasonable, as registry policy, as the 
Arab League's insistence that domain names be real words, or the .cn 
registry's policy (circa 2001, it may have changed) not to allow the 
names of current or former prominent persons in the Chinese Communist 
Party to be allocated, or the .us registry's policy that authoritative 
nameservers be located in the United States. But it isn't a protocol 
specification.

There is no technical necessity to use only 7-bit ASCII. We (IDN-pre-A) 
could have chosen to make the lives of the 7-bit mailers, and others, 
harder. Whether the better possible choice was made was opinion then, 
and now, of a community of engineers with differing skills, and agendas, 
but the ASCII encoding form initially (and unilaterally deployed) by 
Verisign is what was chosen, but not because of any constraint integral 
to the DNS.

My suggestion is that you re-write this as a proposed registry policy to 
bind on the United States, and its contractors, in particular, Verisign 
and ICANN, and their subcontractors, the current and potential TLD 
operators, and of course, the root server operators. I don't think it is 
particularly good policy, but it is policy and if its what you want, 
write it as proposed policy and then sell the hell out of it.

At last I see why Andrew has been asking if anything when punycoded can 
end with a digit, but there is a policy consideration to entertain also 
when asserting a two-octet label may not contain a digit, independent of 
any encoding issue, which I've communicated privately to Tina Dam, and 
eventually I'll post to this, or the IDNAbis, or both, lists.

Section 3 is not useful, because whether you use BNF or not, there is no 
technical content to Section 2, just a policy statement.

Section 4 should be re-written using MUST and MUST NOT terms. You are 
proposing a policy that the IANA be required to implement, to the 
exclusion of all other policies. This is why we have the language from 
2119 and all those ugly upper-case ASCII characters shouting for attention.

Section 5 is simply wrong. Not because no implementations exist which 
are broken, but because we flat don't care. If we did care, we would 
have pulled back the .museum TLD because its length was greater than 3 
and the string wasn't "arpa".

Please don't take this hard, when I proposed that rfc954 be "historic" 
Bob Braden commented that the world would end (slight exaggeration) if 
whois wasn't around and running on port 43, and I'll buy you a beer in 
San Francisco.

Best,
Eric

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 11 Mar 2009 15:51:03 -0400

Sure.

Vint Cerf wrote:
> Eric, et al,
>
> I think it wise to move the discussion to dnsops and to remove from  
> idna-update, please, as has been suggested earlier. IDNAbis does not  
> deal with labels in a way that distinguishes TLDs from any other label  
> position in a domain name.
>
>
> Vint
>
>
>
> Vint Cerf
> Google
> 1818 Library Street, Suite 400
> Reston, VA 20190
> 202-370-5637
> [email-masked]
>
>
>
>
> On Mar 11, 2009, at 1:13 PM, Eric Brunner-Williams wrote:
>
>   
>> Idna-update mailing list
>> [email-masked]
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>     
>
> Idna-update mailing list
> [email-masked]
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
>
>

---

From: Vint Cerf <[email-masked]>
Date: Wed, 11 Mar 2009 15:42:02 -0400

Eric, et al,

Vint

Vint Cerf
Google

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 12 Mar 2009 10:24:45 -0400

> cc-playpens, but it isn't a protocol specification.

It isn't clear to me from the rest of your note: are you collapsing
"text" and "alphabetic" in your remarks there?

At the risk of becoming a broken record (or, to pick a more recently
obsolescent technology, a scratched CD), the precise problem we have
to deal with is the "alphabetic restriction" in RFC 1123.  Some people
think it normative, and others do not.  That's an ambiguity even if
you personally happen to think the text is clear.  Therefore, we need
to fix it.  Even if you think it is policy (as I do), it may still
underpin other protocol issues and therefore properly be the subject
of protocol.  I made a similar argument on list in more detail
yesterday.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 22 Mar 2009 20:42:55 +0100

On Wed, Mar 04, 2009 at 03:13:57PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 27 lines which said:

> For instance, should the ABNF allow fully-numeric top-level domain
> names? There is no *technical* reason to ban them.

Wow, I never noticed this Web page:

http://cr.yp.to/djbdns/dot-local.html

which is interesting to read in the light of the discussion on
fully-numeric top-level domain names :-)

---

From: Todd Glassey CISM CIFI <[email-masked]>
Date: Mon, 23 Mar 2009 07:41:07 -0700

> fully-numeric top-level domain names :-)
really good catch Stephane!

TSG//