Subject: [DNSOP] draft-liman-tld-names-04

From: Joe Abley <[email-masked]>
Date: Thu, 11 Nov 2010 13:42:24 -0500

Hi all,

[sending separately to dnsext and to dnsop, apologies for duplicates]

http://www.ietf.org/id/draft-liman-tld-names-04.txt

is the latest iteration of an effort started quite some time ago to clarify the somewhat vague inference in RFC 1123 and create a more precise specification for the syntax of TLD labels in the DNS. The authors have not received any feedback on this document from the wider DNS community, and would welcome some.

Joe

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 11 Nov 2010 22:19:03 +0100

> is the latest iteration of an effort started quite some time ago to clarify the somewhat vague inference in RFC 1123 and create a more precise specification for the syntax of TLD labels in the DNS.…

Ship it!

   Patrik

---

From: Mans Nilsson <[email-masked]>
Date: Thu, 11 Nov 2010 22:56:56 +0100

> > is the latest iteration of an effort started quite some time ago to clarify the somewhat vague inference in RFC 1123 and create a more precise specification for the syntax of TLD labels in the DN…

++;

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
All this time I've been VIEWING a RUSSIAN MIDGET SODOMIZE a HOUSECAT!

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 12 Nov 2010 07:24:35 +0900

Joe Abley wrote:

> is the latest iteration of an effort started quite some time
> ago to clarify the somewhat vague inference in RFC 1123 and
> create a more precise specification for the syntax of TLD
> labels in the DNS. The authors have not received any feedback
>  on this document from the wider DNS community, and would
> welcome some.

Unlike RFCs 1034 and 1035, it lacks discussion on case
insensitivities of non-ASCII characters, I'm afraid.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 12 Nov 2010 13:42:49 +0100

It does:

>    A Restricted-A-Label is a DNS-Label which satisfies all the following
>    conditions:
> 
>    1.  the DNS-Label is a valid A-Label according to [RFC5890];
> 
>    2.  the derived property value of all code points, as defined by
>        [RFC5890], is PVALID;
> 
>    3.  the general category of all code points, is one of { Ll, Lo, Lm,
>        Mn }.

If you want more clarification than that (and the reference to RFC5890 where it is discussed further), please send text.

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Nov 2010 09:05:22 +0900

> If you want more clarification than that (and the reference to
 > RFC5890 where it is discussed further), please send text.

OK. Add the following:

    As the upper case character corresponding to 'y' with diaeresis
    is not uniquely defined, for example, localized domain names
    are unusable

    It should be noted that, extended case insensitivities beyond
    European characters, such as correspondence between Chinese
    ones, the problem is even more unsolvable.

It should clarify how localized domain names are useless.

						Masataka Ohta

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 13 Nov 2010 09:03:27 +0800

>It should clarify how localized domain names are useless.

-1. There are different documents in which to beat this dead horse.

--Paul Hoffman, Director
--VPN Consortium

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Nov 2010 16:07:07 +0900

> -1. There are different documents in which to beat this dead horse.

I sent text for more clarification because I was requested to do
so by some non-ASCII name.

But, I'm fine if draft-liman-tld-names- is abandoned and all
the RFCs related to localized domain names are declared to be
historic.

						Masataka Ohta

PS

While it is trivially easy to define ASCII representation of
Unicode, it is impossible to operate it, especially when
(extended) case insensitivities are involved.

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 13 Nov 2010 09:44:59 +0100

> It should clarify how localized domain names are useless.

I have two problems with this text. First that I think it is wrong. Secondly that the way IDN and other localization initiatives is by being a) backward compatible [so that the matching algorithm can not be changed -- regardless of what you want] b) because of [a] it pushes the "case insensitivity" matching by asking applications to canonicalize in a way so that if canonicalize(a) == canonicalize(b), then a == b, i.e. not do the canonicalization in the DNS protocol itself. Because the matching function can not be changed.

I therefore, as I think Paul said, suggest we should accept draft-liman-tld-names-04 as it is now, and let the explanation on case insensitivities (etc) are in the RFC589x IDNA2008 RFCs. I further think the references are clear enough so that people that are interested find the sources for the explanation.

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 13 Nov 2010 19:49:17 +0900

Some non-ASCII name wrote:

> I have two problems with this text. First that I think it is wrong.

Then, what is the upper case character corresponding to 'y' with 
diaeresis under localization context of ISO 8859/1, which is what
you are using in your mails as:

	From: =?iso-8859-1?Q?Patrik_F=E4ltstr=F6m?= <[email-masked]>

?

 > Secondly that the way IDN and other localization initiatives is
> by being a) backward compatible [so that the matching algorithm
 > can not be changed -- regardless of what you want] b) because of
> [a] it pushes the "case insensitivity" matching by asking
 > applications to canonicalize in a way so that if
> canonicalize(a) == canonicalize(b), then a == b, i.e. not do
 > the canonicalization in the DNS protocol itself. Because the
> matching function can not be changed.

If extended case insensitivities or canonicalization is not
handled by DNS severs and resolvers, which requires universal
definition, it causes unsolvable problems of:

	1) cache inefficiency

	2) wasted operational effort for synchronization of
	multiple zones with effectively same FQDN

	3) exponential explosions of the number of labels with
	effectively same FQDN

	4) doubly exponential explosions of the zones with
	effectively same FQDN for DNSSEC

That's why I wrote postscript in my previous mail.

PS> While it is trivially easy to define ASCII representation of
PS> Unicode, it is impossible to operate it, especially when
PS> (extended) case insensitivities are involved.

> and let the explanation on case insensitivities (etc) are in
 > the RFC589x IDNA2008 RFCs.

It's simply not operational.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Sat, 13 Nov 2010 15:26:34 +0100

On 13 nov 2010, at 11.49, Masataka Ohta wrote:

> Then, what is the upper case character corresponding to 'y' with diaeresis under localization context of ISO 8859/1, which is what

In ISO-8859-1, 0xE4 is ä, and 0xF6 is ö.

There is no 'y' with diaeresis in that string.

   Patrik

---

From: Suzanne Woolf <[email-masked]>
Date: Sun, 14 Nov 2010 20:02:40 +0000

On Sat, Nov 13, 2010 at 09:44:59AM +0100, Patrik F?ltstr?m wrote:
> 
> I therefore, as I think Paul said, suggest we should accept
> draft-liman-tld-names-04 as it is now, and let the explanation on
> case insensitivities (etc) are in the RFC589x IDNA2008 RFCs. I
> further think the references are clear enough so that people that
> are interested find the sources for the explanation.

+1.

Suzanne

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 15 Nov 2010 18:06:49 +0900

Some non-ASCII name wrote:

> In ISO-8859-1, 0xE4 is <some garbage>, and 0xF6 is <some garbage>.

You MUST learn to use ASCII only, if you want international
communication in English.

> There is no 'y' with diaeresis in that string.

That does not answer my question:

    Then, what is the upper case character corresponding to 'y' with
    diaeresis under localization context of ISO 8859/1, which is what
    you are using in your mails

The reality is that, with ISO 8859/1, which is what you are using
in your mails, plain 'Y' without diaeresis is used as a capital
form of both plain 'y' without diaeresis and 'y' with diaeresis.

Moreover, even though 'C' with cedille exists in ISO 8859/1, it
is seldom used and plain 'C' is used as capital form of 'c' with
cedille.

That's the case insensistivities of the real world, regardless
of how Unicode defines case insensitivity. Worse, localized
domain names must but can not handle the real world issues.

Note that this (ISO 8859/1 for French) is the simplest
localization beyond ASCII for English, French, Japanese etc.

We don't need Chinese characters to show localized domain
names are hopeless.

						Masataka Ohta

---

From: Patrik Fältström <[email-masked]>
Date: Mon, 15 Nov 2010 17:22:49 +0100

> form of both plain 'y' without diaeresis and 'y' with diaeresis.

No, that statement is not correct. The mapping you might want depends on context, and that not only because of language, but also where the language is used. I.e. it depends on what locale you are using.

> domain names must but can not handle the real world issues.

And that is why case insensitivity is NOT part of IDNA2008. Instead only case folded code points are allowed.

See RFC 5895 and the RFC 5890 series IDNA2008 RFCs.

5895 Mapping Characters for Internationalized Domain Names in
     Applications (IDNA) 2008. P. Resnick, P. Hoffman. September 2010.
     (Format: TXT=16556 bytes) (Status: INFORMATIONAL)

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 06:07:28 +0900

Some non-ASCII name wrote:

> No, that statement is not correct. The mapping you might want
> depends on context, and that not only because of language,
> but also where the language is used. I.e. it depends on what
> locale you are using.

IT'S ENOUGH THAT YOU ADMIT "IT DEPENDS". Remember that you wrote
"Because the matching function can not be changed." in your
mail on November 13.

And, under ISO 8859/1, it does not even depend, because ISO 8859/1
does include 'y' with diaeresis but not 'Y' with diaeresis, which
means all CAPITALIZED representations (see above for an example),
all you can use is plain 'Y' without diaeresis.

> And that is why case insensitivity is NOT part of IDNA2008.

>> insensitivities of non-ASCII characters, I'm afraid.

is wrong.

Then, we have agreed that localized domain names in IDNA2008 can
not handle case insensitivities.

> Instead only case folded code points are allowed.

That's not the point.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Nov 2010 16:35:33 -0500

> "Because the matching function can not be changed." in your

It seems to me that screaming on the list and taking two different
phrases out of context and mashing them together is a demonstration
that you are not interested in good faith conversations.  Moreover,

> And, under ISO 8859/1, it does not even depend,

ISO 8859-1 is completely irrelevant here, because how you get to the
point of having a U-label is totally out of scope for the IDNA2008
specification.  But whatever you do to get to that point, the U-label
has nothing whatever to do with ISO 8859-1.

> not handle case insensitivities.

It is certainly true that the DNS-protocol case preservation but case
insensitivity matching rules are not internationalized exactly as one
might like in IDNA2008.  Without DNSng, I have no idea how to solve
that.  But you seem to be willfully ignoring that IDNA2008 actually
does address this, although in an uncomfortable and somewhat
unsatisfying way.  One could be forgiven for imagining that you
haven't bothered to read the RFCs you are insisting don't address the
issue you're talking about.

The draft does not need to address this point, because the point is
addressed elsewhere.  Every draft on internationlization is not an
opportunity to re-explore the rathole down which the IDNABIS working
group laboured for several years.  IDNA is shipping.  All the current
draft does is permit TLDs that are in conformance with IDNA2008,
except that it attempts to make the change as small as possible in
order to try to minimise the possibility of surprises from software
that had understood RFC 1123 as protocol and not policy.

I think the document should be shipped as soon as possible.

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 06:49:32 +0900

Andrew Sullivan wrote:

> ISO 8859-1 is completely irrelevant here,

If your local encoding is ISO 8859/1, you can input 'Y', but not
'Y' with diaeresis.

If your local encoding is Unicode but you are accustomed to ISO
8859/1 environment, you will input 'Y', but not 'Y' with diaeresis.

It does not affect abstract definitions of IDNA2008 but does
affect DNS operations.

> because how you get to the
> specification.

It's totally irrelevant.

> that.

I have no idea how it can be solved with DNSng. What is your
proposal for the DNSng?

> But you seem to be willfully ignoring that IDNA2008 actually
> unsatisfying way.

The problem is that localized domain names are not operational
at large scale at least with the current DNS.

> IDNA is shipping.

The problem is that localized domain names are not operational
at large scale at least with the current DNS.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Nov 2010 17:15:34 -0500

> It does not affect abstract definitions of IDNA2008 but does

Everyone who ever makes this kind of remark seems to imagine that the
tools that they are using never affect the people using them.  This is
a preposterous assumption, akin to maintaining that it was impossible
to learn to drive a car because horses don't have steering wheels.

Of course it is true that different people in different environments
have a hard time spelling things in another language.

That is simply not an argument that localization can't possibly work.
It is instead an argument that localization in a globalized system
brings with it a bunch of challenges that cause users some difficulty.
It is then a matter of trading off the difficulty of communicating
when there are different ways of spelling "the same thing" (e.g. an
ASCII-based one and, say, a Han-based one) against the difficulty for
a user who just doesn't have an ASCII keyboard or even a left-to-right
user input context.

Of course that is hard.  Nobody ever said it wasn't.  But there is a
gap between "hard" and "totally impossible", and I do not see any
advantage in pretending that such a gap doesn't exist.

A

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

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 07:33:50 +0900

> but also where the language is used. I.e. it depends on what

How the locale information could be supplied?

Though, in general, it may be implied by TLDs, there is no
locale information for TLDs.

Should we extend TLD format to include locale information
for (extended) case insensitivity with a case insensitivity
description language?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 07:46:08 +0900

> a preposterous assumption,

I already gave an example of capital form of 'c' with cedille is
often plain 'C' without cedille and seldom 'C' with cedille, even
though tools of ISO 8859/1 and Unicode support 'C' with cedille.

It's a fact, not an assumption.

Moreover, it is a fact that ISO 8859/1 includes 'y' with
diaeresis but not 'Y' with diaeresis, which means people
accept plain 'Y' without diaeresis as capital form of 'y'
with diaeresis whenISO 8859/1 was defined.

That is, people affect the tools.

Now, may I ask where are facts supporting *YOUR* assumptions?

						Masataka Ohta

---

From: "]ke Nordin" <[email-masked]>
Date: Mon, 15 Nov 2010 23:51:28 +0100

> for (extended) case insensitivity with a case insensitivity

I think that is rather far out of scope for the document in question.

If every single standards document must address _every_  potential
issue, the density of IETF work would have a significant Schwarzschild
radius. With 5k RFCs, one would imagine that it should be rather clear
that problems are solved in small steps and separate, independent
pieces of work.

Since I perceive that draft-liman-tld-names-04 solves more problems
than it causes, I believe that it is safe and good form to publish it
as is. 

-- 
 .
 Ake Nordin <[email-masked]> Net/Unix/telecom geek, Senior consultant.
 Netia Data AB,  Forradsv 7-9,  SE-18141 Lidingo SWEDEN  +46 704 66 01 99

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 15 Nov 2010 18:07:36 -0500

> though tools of ISO 8859/1 and Unicode support 'C' with cedille.

Changing the example does not make your case any stronger.  (And
actually, you're now well into the land already staked by
J.F.C. Morfin and his crowd of adherents.  In my opinion, Jefsey's
understanding of how French works is not exactly in line with what
l'Académie says, but you're welcome to go and read his views for
yourself.)

> That is, people affect the tools.

If course they do.  And the tools affect the people.  Technology
shapes us even as we shape it.  English speakers have learned that,
for comparison purposes, EXAMPLE and example match, but it's not
actually quite as simple as that.  For instance, there is a sorting
rule in English that sorts capital letters before lower case; so if
you had a list with EXAMPLE, Example, and example in it, they would
sort in that order.  And sometimes case is important, as when you are
correcting the spelling of something that ought to be capitalized in
some cases and not others.  ("The University's Senate made a statement
that the role of the university in the modern context has changed."
Case can change meaning.)  Not all of this can be captured in the DNS,
either, but competent speakers of the language have learned how to
move around in this context.

> Now, may I ask where are facts supporting *YOUR* assumptions?

I'm not sure which assumptions you're talking about.  If you're
talking about the one in which I was arguing that technology shapes us
just as surely as we shape it, then I'm afraid the demonstration of
that is altogether off topic for this list.  But if you don't believe
me, I can suggest some elementary reading for you.  You may find her
totally inaccessible, but I find Donna Haraway on cyborgs to be an
excellent place to start.

Anyway, you have not demonstrated even a little bit that all of this
needs to be included in the document, since it does not pertain
directly.  You don't even appear to be trying to make such an
argument, so I think you're just ranting because you don't like IDNA.

A

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

---

From: David Conrad <[email-masked]>
Date: Mon, 15 Nov 2010 13:19:33 -1000

On Nov 15, 2010, at 11:35 AM, Andrew Sullivan wrote:
> Every draft on internationlization is not an
> group laboured for several years.  

+<U+221E>

> All the current

While I agree with the intent, I suspect we'll be revisiting this issue in the relatively near-term when folks realize that "1*63(ALPHA)" means they can't have their "fun4u" or "2go" TLDs.

> I think the document should be shipped as soon as possible.

Agreed.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 09:15:00 +0900

Andrew Sullivan wrote:
> Changing the example does not make your case any stronger.

It's merely that you ignored one of my examples.

It is not necessary to make my cases any stronger against
your weak statement:

> might like in IDNA2008.

Note again that my cases are for French localization with ISO
8859/1, the least difficult localization beyond ASCII, which
is already enough to show IDNA2008 unusable.

Imagine what will happen beyond that.

> I'm not sure which assumptions you're talking about.

That's fine. You don't have to show any facts.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 16 Nov 2010 09:22:44 +0900

> I think that is rather far out of scope for the document in question.

Then, how the locale information for TLDs could be supplied?

> issue, the density of IETF work would have a significant Schwarzschild

I'm not saying that the document should specify a case
insensitivity description language nor that IETF should
specify the language.

But, there should be a field in TLD names to store the locale
information.

						Masataka Ohta

---

From: Richard Clayton <[email-masked]>
Date: Tue, 16 Nov 2010 01:00:10 +0000

In message <[email-masked]>, Masataka Ohta
<[email-masked]> writes

>often plain 'C' without cedille 

That, as I understand it, is the convention in mainland France.

>and seldom 'C' with cedille,

That, as it has been explained to me by the natives, is the convention
in Canadian French.

> even

These conventions (which I first came across when building multilingual
word processors in the early 1980s) very much predate these standards...

... I've no doubt that you can find erudite people in both France and
Canada to discuss how formally specified these rules are. My
understanding of these rules comes solely from ensuring that the locals
didn't get overexcited when we shipped product :-)

What it means is that if you're writing a word processor and forcing
material into upper case you need to understand if your text is written
in "French" or "Canadian French". If you're not sure -- or your text is
labelled "British English" then you have to take an arbitrary view as to
what the right thing to do might be, which is probably to make yourself
look good in Paris... the people in Montreal will be annoyed, but will
understand your dilemma.

>with diaeresis whenISO 8859/1 was defined.

As a practical matter, if you're trying to avoid most (not all) of the
gotchas in case insensitive coding, you don't upper case strings, but
you force anything which is in upper case to a lower case form :)

- -=-=-=-

Anyway... since we're meant to be discussing the document, I admit to
being entirely puzzled by this section:

The reason I'm puzzled is that RFC5890 doesn't discuss what "property"
is and PVALID seems to be in a table in a different document (and so
doesn't appear in RFC5890 at all). ie: I think the reference to RFC5890
in #2 may be a typo.

I would also like to know where I'd go to look up what a category is ...

... I think what this is intending to say is that you can have a TLD of
".2go" but only if there's an xn-- at the front of the whole thing :)

- -- 
[email-masked]                     "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 16 Nov 2010 08:15:06 -0500

On 11/15/10 6:19 PM, David Conrad wrote:
> ...

well, there are issues that the original idn, and the later idnabis 
working groups didn't examine as exhaustively as others, and to assume 
that every issue related to i18n and/or l10n on or off the wire was 
adequately addressed by one or both is very, very generous.

> While I agree with the intent, I suspect we'll be revisiting this issue in the relatively near-term when folks realize that "1*63(ALPHA)" means they can't have their "fun4u" or "2go" TLDs.

That one was surfaced at the Mexico ICANN, with some bright young 
thing dreaming of ".4u", presenting at least two problems in presumed 
policy land.

Eric

P.S. The bright young thing's idea has been on a major registry 
platform provider's list of applications-in-hand subsequent to the 
Mexico meeting.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Nov 2010 09:42:40 -0500

> doesn't appear in RFC5890 at all). ie: I think the reference to RFC5890

Yeah, I was afraid of this when I saw it before.  You've confirmed my
fear.  The references to IDNA2008 in section 1 of the draft should be
to the entire document set (RFC 5890, RFC 5891, RFC 5892, and RFC
5893).  Also, the text should undoubtedly refer specifically to
IDNA2008 rather than just "IDNs"; and the spelling of
"Internationalized" should revert to its American version, no matter
how one feels that is wrong, because the reference is usually to the
title of the document set and it's spelled with the "z" there.  The
reference in item 2 needs to be changed, because the derived property
value is defined by RFC 5892:

   This document reviews and classifies the collections of code points
   in the Unicode character set by examining various properties of the
   code points.  It then defines an algorithm for determining a derived
   property value.  It specifies a procedure, and not a table, of code
   points so that the algorithm can be used to determine code point sets
   independent of the version of Unicode that is in use.

As an aside, I'll note that this sort of picky editorial issue is, to
me, yet another indication that the document is actually basically
ready to ship.

> I would also like to know where I'd go to look up what a category is ...

The category is a property of each Unicode code point.  I think you
can probably get enough to understand the current draft by reading all
of the IDNA2008 documents (if you go to the RFC Editor search page and
just use "IDNA2008" as your search string, you'll get them all.  But
they're RFCs 5890 through 5894, with the latter being non-normative
informational material.  You might want to have a look at 5895 too.
But if that's not enough, you'll need to read the Unicode
specification.  The whole thing is available from unicode.org.  

> ".2go" but only if there's an xn-- at the front of the whole thing :)

I think what you mean is that xn--2go would be a valid U-label, and
therefore would be a possible label under the rules in the draft, but
that "2go" itself is not a label permitted under these rules because
it fails the traditional "will be alphabetic" restriction in the
discussion in RFC 1123 (and it is not a possible U-label because it is
all ASCII).  If so, then yes, exactly right.

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

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Nov 2010 09:53:08 -0500

> adequately addressed by one or both is very, very generous.

I don't think that anyone was supposing that.  I was simply arguing
that we can't re-open the entire protocol every time someone wants to
write something that depends on it.  If one thinks that IDNA2008 is
broken or otherwise wrong, the right thing to do is to go write the
IDNA2008 Considered Harmful draft, not to try to sneak those
criticisms in through the back door of a pure clean-up document
designed only to permit the use of IDNA2008 in the top level.  If
there is such a Considered Harmful draft floating about, then ICANN
has the obligation to make decisions about whether to form its policy
in light of that document.  The IETF is about protocol, and all this
document is trying to do -- and it is explicit about this -- is to
relax (carefully) a restriction that may or may not have been
understood somewhere as a protocol restriction.

> That one was surfaced at the Mexico ICANN, with some bright young thing 
> dreaming of ".4u", presenting at least two problems in presumed policy 
> land.

Note that .4u is still simply not allowed by RFC 1123 or by this
draft.  That is an all-ASCII label, not a U-label, and it is not
alphabetic.  Therefore, not allowed.  If someone at ICANN wants to
change that, s/he will need to write a draft.  Or, of course, ignore
the RFCs published by the IETF.  I'm sure the people at the ITU would be
happy with that latter outcome.

A

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

---

From: Suzanne Woolf <[email-masked]>
Date: Tue, 16 Nov 2010 15:59:53 +0000

> me, yet another indication that the document is actually basically

+1. The rest is interesting and important but can be pursued
separately from the question of last-calling this particular document
and the specific specification fix it proposes.

Suzanne

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Nov 2010 16:06:37 +0000

On Tue, 16 Nov 2010, Andrew Sullivan wrote:
> draft.

According to my reading of RFC 1123 it is allowed, and IDNA depends on it
being allowed. The normative text says that anything that isn't a dotted
quad IP address should be treated as a domain name. It's probably sensible
to forbid all-numeric TLDs, but it isn't necessary to forbid mixed numeric
/ alphabetic / hyphenated TLDs.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Nov 2010 06:16:13 -1000

Tony,

On Nov 16, 2010, at 6:06 AM, Tony Finch wrote:
> According to my reading of RFC 1123 it is allowed,

1123 says:

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

Note that it says 'will be alphabetic' not 'will contain an alphabetic'. This is, I presume, the rationale for 1*63(ALPHA) in the ABNF. I was suggesting that this restriction will likely be revisited in the near future (but that's not to say that this document shouldn't go forward).

Also, just speaking of current policy, 2-letter TLDs are restricted to what's in the ISO-3166 list (or, to be pedantic, are in practice restricted to what's listed as 'officially assigned', 'exceptionally reserved', or 'transitionally reserved' code elements in http://www.iso.org/iso/iso-3166-1_decoding_table).

> and IDNA depends on it being allowed.

Sorry?

Regards,
-drc

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 16 Nov 2010 11:48:18 -0500

On Tue, Nov 16, 2010 at 04:06:37PM +0000, Tony Finch wrote:

> quad IP address should be treated as a domain name.

Define what you mean by "normative text".  You're quite right that the
"will be alphabetic" restriction is in the Discussion, and therefore
can be construed as not actually part of the protocol (that's actually
how I read it).  But the argument has been that the Discussion segment
amounts to a constraint on the protocol, or anyway may well have been
interpreted that way in running code.  We don't know.  (And of course,
as usual in the DNS, we don't have any way of checking.)

You're quite right that the "will be alphabetic" stricture has to be
released for TLDs to be able to do IDNA at all: every one of them
contains "--" and that's not alphabetic.  So I read the document as
trying to relax that rule just exactly enough to allow A-labels in the
TLDs, without relaxing everything.  The "don't relax everything" goal
is to make the smallest change needed so that if there are any bad
effects, they're not magnified more than they ought to be.

Given what I have seen in other TLD-checking type code, I'd bet a
pretty good lunch that anything _starting_ with a digit in the top
level will run into all sorts of troubles.  There's probably some
heuristic software out there that checks the top-most label, looks for
a digit in the first character, and treats the set of labels as an IP
address if there is one.

To me, the justification for the U-label having to be a letter, then,
is that such a label could get passed in as a U-label form, and if the
carelessly-written code is running in a Unicode environment it will do
exactly the same thing as I just described.  So the draft seems to me
to make the most conservative change it can.  Even if I don't like it,
the top level is different from other levels in the DNS, and we need
to be careful there.

A

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

---

From: Tony Finch <[email-masked]>
Date: Tue, 16 Nov 2010 17:02:41 +0000

> 1123 says:

in the informative text

> Note that it says 'will be alphabetic' not 'will contain an alphabetic'.

The prediction has already been broken by IDNA.

I read it as a statement of the then-current TLD allocation policy, not
the host name syntax, and an explanation of why the full syntactic
check will not lead to ambiguity.

> Also, just speaking of current policy, 2-letter TLDs are restricted to
> what's in the ISO-3166 list

This is also part of the allocation policy not the syntax. I note you
didn't say "two character" :-)

> > and IDNA depends on it being allowed.

IDNA TLD A-labels are not alphabetic. Non-IDNA software can still use them.

The problem with this document is it mixes up syntax and policy and the
A-label and U-label layers. I think the raw syntax should remain as simple
as possible and all restrictions such as alphabetic-only should be left to
the policy layer. It is good to document the policy concisely as in this
document, but it should be clear that it applies to the form of domain
names as seen by users and not to lower level code.

Tony.

---

From: David Conrad <[email-masked]>
Date: Tue, 16 Nov 2010 07:19:21 -1000

> On Tue, 16 Nov 2010, David Conrad wrote:

True, but back when 1123 was written (and when code was developed based on it), I suspect the distinction wasn't made.

> The prediction has already been broken by IDNA.

Yes, hence the draft being discussed.

> I think the raw syntax should remain as simple
> the policy layer.

I'd think that if this were done, it wouldn't be a minimal change and would open up a larger discussion. While (as I indicated) I think that this discussion will happen eventually, I'd personally like to fix the current specification brokenness caused by the introduction of IDNs in the root now and deal with the more general problem later.

Regards,
-drc

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 10:19:28 +0100

On Thu, Nov 11, 2010 at 01:42:24PM -0500,
 Joe Abley <[email-masked]> wrote 
 a message of 15 lines which said:

> is the latest iteration of an effort started quite some time ago to
> clarify the somewhat vague inference in RFC 1123 and create a more
> precise specification for the syntax of TLD labels in the DNS.

Nice attempt but, as I have already said
<http://www.ietf.org/mail-archive/web/dnsop/current/msg07058.html>,
there is zero technical reason to limit the TLD to alphabetic
characters and therefore, the rule:

traditional-tld-label = 1*63(ALPHA)

is both a new rule (it was not in RFC 1034 or 1035) and a bad one.

I object to the creation of new rules disguised as clarifications.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 10:24:09 +0100

On Tue, Nov 16, 2010 at 11:48:18AM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 47 lines which said:

> level will run into all sorts of troubles.

Correct, but it is not a sufficient reason to hardwire it in an IETF
standard. For instance, .MUSEUM or .TRAVEL had (and still have) a lot
of problems with broken regular expressions "[a-z]{2,4}" but we did
not update RFC 1123 to add a length limit to TLDs.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 10:26:30 +0100

On Tue, Nov 16, 2010 at 05:02:41PM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 43 lines which said:

> I read it as a statement of the then-current TLD allocation policy,
> not the host name syntax, and an explanation of why the full
> syntactic check will not lead to ambiguity.

I fully agree and this is why I think that the traditional-tld-label
rule in draft-liman-tld-names-04 is a NEW rule, not a clarification.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 10:36:59 +0100

[Side-issue, not really relevant for draft-liman-tld-names.]

On Tue, Nov 16, 2010 at 01:00:10AM +0000,
 Richard Clayton <[email-masked]> wrote 

> That, as I understand it, is the convention in mainland France.

No, the rule is that composed characters are composed characters, in
upper case or in lower case.

At the time of the typewriters, there *was* a tendency to ignore
accents and cedillas on uppercase characters because it was impossible
to type them. Now that everyone uses word processor, accents on
uppercase characters are back (but not at 100 %).

Look in a second-hand bookshop: cheap books published between 1900 and
1990 often lack accents and cedillas in their titles. That was the
time of typewriters. (Expensive books were not affected.)

> ... I've no doubt that you can find erudite people in both France
> and Canada to discuss how formally specified these rules are.

Do note that not everyone follow the official rules, in the same way
that not every implementor or sysadmin follow the RFCs :-)

Today, many people, by laziness or ignorance, omit the accents and
cedillas on uppercase characters.

On Mon, Nov 15, 2010 at 06:07:36PM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 43 lines which said:

> In my opinion, Jefsey's understanding of how French works is not
> exactly in line with what l'Académie says, 

L'Académie Française <http://www.academie-francaise.fr/> is a bunch of
old and disconnected people so they have little influence on how to
actually write French, specially on the Internet. But, anyway, their
stand on composed uppercase characters is at
<http://www.academie-francaise.fr/langue/questions.html#accentuation>.

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Nov 2010 11:20:56 +0000

On Tue, 16 Nov 2010, Andrew Sullivan wrote:
>
> Define what you mean by "normative text".

Normative text specifies requirements. (This is the usual meaning of the
word.) Text in "DISCUSSION" sections is not normative. RFC 1123 section
1.3.1 says:

         Under many of the individual topics in this document, there is
         parenthetical material labeled "DISCUSSION" or
         "IMPLEMENTATION".  This material is intended to give
         clarification and explanation of the preceding requirements
         text.  It also includes some suggestions on possible future
         directions or developments.

Therefore the "will be alphabetic" phrase is not a requirement, it's part
of an explanation of how the syntax works in practice.

> But the argument has been that the Discussion segment amounts to a
> constraint on the protocol, or anyway may well have been interpreted
> that way in running code.  We don't know.

This is why you need to be clear about the layering. If this constraint
had been implemented in low-level non-policy code then IDNA TLDs would not
work.

There is quite a lot of policy enforcement code that has detailed
knowledge of which TLDs are valid, and that is perfectly fine because it
is operating at the policy layer not the protocol syntax layer, and is
obliged to keep up with changes in allocation policy.

> So I read the document as trying to relax that rule just exactly enough
> to allow A-labels in the TLDs, without relaxing everything.

I believe that no requirement needs to be relaxed to allow A-labels. A
clarification might be helpful.

What this document does is introduce new syntactic restrictions, by
specifying policy-layer stuff as protocol syntax.

> There's probably some heuristic software out there that checks the
> top-most label, looks for a digit in the first character, and treats the
> set of labels as an IP address if there is one.

That is blatantly broken. There is no need for any heuristic to tell IP
addresses and host names apart. This kind of code should be mocked, not
accommodated.

> Even if I don't like it, the top level is different from other levels in
> the DNS, and we need to be careful there.

Careful is for policy not mechanism.

Tony.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 12:32:17 +0100

On Wed, Nov 17, 2010 at 11:20:56AM +0000,
 Tony Finch <[email-masked]> wrote 
 a message of 63 lines which said:

> That is blatantly broken.

Yes.

> There is no need for any heuristic to tell IP addresses and host
> names apart.

To elaborate on that: if a program receives the string 192.0.2.4 and
the TLD ".4" is delegated, the tie is broken by application of a
requirment of RCF 1123 "The host SHOULD check the string syntactically
for a dotted-decimal number before looking it up in the Domain Name
System."

So, there is no ambiguity: 192.0.2.4 is always an IP address, even if
ICANN delegates ".4".

[My point is that draft-liman-tld-names is probably unecessary but,
anyway, it should not introduce new rules such as forbidding digits in
ASCII TLDs. A simpler document saying "The sentence 'the highest-level
component label will be alphabetic' in RFC 1123 was a statement of
fact at this time, NOT a normative protocol requirment." would have
been sufficient.]

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Nov 2010 23:15:04 +1100

> So, there is no ambiguity: 192.0.2.4 is always an IP address, even if

Except there are plenty of applications that don't do this so it is 
a real problem.
 
> _______________________________________________
> 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: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Nov 2010 07:19:07 -0500

> clarification might be helpful.

If no requirement is needed, then no document is needed, because the
policy realm was ceded to ICANN some years ago.  We can remain quiet
and wait for someone at ICANN to write a document somewhere that
clarifies that they have changed the policy that used to be expressed
in RFC 1123.

> addresses and host names apart. This kind of code should be mocked, not

To my mind, this is a way of saying that anyone who has to live with
broken implementations by people who half-understand the huge volume
of DNS-related RFCs is just sweet out of luck.  Too bad for them.  Is
that really what we want to say?

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 17 Nov 2010 07:57:27 -0500

On 11/16/10 11:16 AM, David Conrad wrote:
> Note that it says 'will be alphabetic' not ...

Were one to stop at the policy statement: "a valid host name can never 
have the dotted-decimal form #.#.#.#", rather than the implementation 
detail "since at least the highest-level component label will be 
alphabetic", then one could consider whether labels consisting of at 
least one instance of a label consisting of a character string 
representing a digit in excess of 256 within the first four or fewer 
labels meets the rule.

I'm not suggesting that there is a compelling need for a TLD "257", or 
for a TLD "255" with a registration restriction that any sub-domain 
must contain a non-digit or have a value as a digit string greater 
than 256 within one of the first three lables, but that does seem to 
be consistent with the narrowest reading of the policy, and the least 
change needed to correct the associated error in the implementation 
detail.

> Also, just speaking of current policy, 2-letter TLDs are restricted to ...

This is the other leg of the test. The iso3166/MA has an allocation 
model, and a use model. The allocation model appears to be sparse in 
the 676 code element space available through an alpha-2 code 
mechanism, and the following property of the model is generally 
overlooked:

"ISO 3166-1 specifies a series of code elements for user purposes 
which the ISO 3166/MA will never use in the updating process of the 
standard. To quote from ISO 3166-1:2006, clause 8.1.3 User-assigned 
code elements:

If users need code elements to represent country names not included in 
this part of ISO 3166, the series of letters AA, QM to QZ, XA to XZ, 
and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA to XZZ, and ZZA to 
ZZZ respectively and the series of numbers 900 to 999 are available.

These code elements are at the disposal of users who need to add 
further names of countries, territories or other geographical entities 
to their in-house application of ISO 3166-1."

Source: http://www.iso.org/iso/customizing_iso_3166-1.htm,
linked to from
http://www.iso.org/iso/support/country_codes/iso_3166_code_lists/iso-3166-1_decoding_table.htm

When ICANN proposed "two characters", terrain the authors of rfc2929 
went over in 2000, I wrote pointing out that it was proposing to 
expand the number of reserved code points from 676 code elements to 
1296 code elements. While some prudence concerning the scale 
limitations of the current iso3166/MA's allocation model and the size 
of jurisdictionally, geographically, or economically distinct entities 
and regional intellectual property associations provided allocations 
is reasonable, the history of changes by the iso3166/MA does not 
suggest that it needs to be protectively anticipated by a step-change 
doubling of its allocatable values.

"ICANN predicts breakups of most major countries" or "ICANN to 
recognize Indian Nations", and I'm particularly fond of the latter and 
look forward to the film at 11, could explain this sudden solicitude 
towards an apparently insufficiently future-aware iso3166/MA, but I 
suspect that is not the actual motivation.

To preclude the AA, QM to QZ, XA to XZ, and ZZ, and the series AAA to 
AAZ, QMA to QZZ, XAA to XZZ, and ZZA to ZZZ respectively and the 
series of numbers 900 to 999 range, from their intended use as user 
defined (and here "user" is the applications which are aware of the 
use made of an identifier, hence, applications which use the content 
of the IANA root zone) code points, unique within an application 
domain (the IANA root zone), is a peculiar kind of clarification.

I'm fine with ICANN Board deciding that "xxx" is not a valid gTLD 
label, or that "4u" is not a valid gTLD label, or whatever. However, 
the claims of technical necessity can be independent of the policy 
goals of such bodies, and probably should be.

Personally I'm as indifferent to the "will break" claim for inet_* as 
I was to the claim of brokenness for sizeof(tld) > 4, and for "can't 
work in China" for various bits of the IDN/IDNA chain of deliverables.

The resolution, external to authorized users, of mappings in the .mil 
and subordinate zones, is optional, not mandatory. The resolution of 
mappings in the .中国 zone, from November 2001 to the very recent 
present, by resolvers external to the region, was optional, not 
mandatory. The resolution of stupid-domain-name.257 is as optional, 
and the continued operation of IDN-unaware operating system product, 
or IMP-aware operating system product, decades after their technical 
obsolescence, as door stops and space heaters and print servers is 
appropriate use.

I don't see the compelling rational for this draft by a standards 
body, and I'm unmoved by the non-standards representations of utility 
and necessity.

I'm also unmoved by the representations of utility and necessity for 
v6 and DNSSEC as a mandatory to implement features of new gTLD 
operators, and no others.

My two beads worth,
Eric

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 22:05:06 +0900

Andrew Sullivan wrote:

> If one thinks that IDNA2008 is
> IDNA2008 Considered Harmful draft,

Maybe, someone, maybe, interested in writing draft on how
zone synchronization by BNAME or whatever is hopeless,
even though it is so obvious for Chinese localization.

Moreover, you should write your own ID on DNSng, which should
solve the seemingly unsolvable problem above.

But, my contribution that Latin/French localization
causes the same problem as Chinese localization does
not require more explanations.

					Masataka Ohta

---

From: James Mitchell <[email-masked]>
Date: Thu, 18 Nov 2010 00:08:13 +1100

Do we really want to say to 3com (probably a bad example, but go with the concept) that they cannot have a TLD when their competitors can? And if you tell me that 3com can compromise and apply for a 'valid' TLD, then what happens should/when we change the rules to allow these characters in TLDs? "Sorry 3com, the first time we didn't want to punish the people who made assumptions about the composition of TLDs". The people who are punished are the applicant, 3com, because their TLD does not work!

With that said, I'm fairly certain that the ICANN Draft Applicant Guidebook by tells applicants that their TLD may not work. I don't quite see how the IETF (don't want to break existing applications) and ICANN (it might not work, no comment on when it will as it is up to application developers) align.

As a thought, consider names written in the Arabic script. Being a cursive script, how is a TLD applicant expected to separate 'words' in a top level domain without the use of a hyphen or equivalent. Removing the spaces will cause the characters to join, and the meaning lost (besides which the A-label will contain hyphens anyway?!). I'm far from qualified to talk authoritatively on the Arabic script, or how it will be used in domain names, however I do know of parties that will be applying for Arabic TLDs - are we to exclude these applicants?

My thoughts are this draft should re-iterate the requirement "The host SHOULD check the string syntactically for a dotted-decimal number before looking it up in the Domain Name System", clarify whether dotted decimal includes .256+, and mention that any TLD may not work due to assumptions on the composition of a TLD in applications not conforming to this RFC. It should even give guidance into how one should 'validate' TLDs so this does not happen in the future; i.e. update from IANA.

James

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Andrew Sullivan
> Sent: Wednesday, 17 November 2010 11:19 PM
> To: [email-masked]
> Subject: Re: [DNSOP] draft-liman-tld-names-04
>

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 22:06:56 +0900

> cedillas on uppercase characters.

Yes, "many people". That's the real world dnsop must face.

Thank you to have confirmed my point.

And, as for capitalization of 'y' with diaeresis, even more people
use 'Y', because it is formally enforced by an ECMA/ISO/IEC standard.

						Masataka Ohta

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 17 Nov 2010 08:41:50 -0500

On 11/17/10 8:08 AM, James Mitchell wrote:

> Do we really want to say to 3com ...

Please see rfc1591. An application by the Comintern, also known as the 
Third International, for "3int", could be rfc1591 consistent. An 
application by a brand owner could not be rfc1591 consistent.

The interest in stuffing the IANA root with brands is a peculiar 
interpretation of a general policy responsibility.

> With that said, I'm fairly certain that the ICANN Draft Applicant Guidebook by tells applicants that...

Please don't fail to differentiate ICANN's draft general liability 
limiting language from its specifically meaningful draft language on 
strings, resolvability, stability and so on.

> As a thought, consider names written in the Arabic script. Being a cursive script...

The subject has been given considerable thought.

> My thoughts are this draft should re-iterate the requirement "The host SHOULD ...

It is a redundant requirement, and there is no shortage of 
implementations in the field which "know" what the IANA root may 
contain, and are kind enough to enforce their static knowledge, until 
updated. Rinse and repeat.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 14:47:12 +0100

On Wed, Nov 17, 2010 at 10:06:56PM +0900,
 Masataka Ohta <[email-masked]> wrote 

> Thank you to have confirmed my point.

Just for the record: I never expressed an agreement with Masataka Ohta
(to agree, I would first need to understand what he says) and I
believe this entire issue is completely unrelated to
draft-liman-tld-names.

---

From: Tony Finch <[email-masked]>
Date: Wed, 17 Nov 2010 14:07:42 +0000

> that really what we want to say?

Give them a clarifying RFC that they can use to convince their suppliers
to fix.

Tony.

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 23:09:25 +0900

> Just for the record: I never expressed an agreement with Masataka Ohta

For a fact based argument, it's irrelevant to whom you intended
to show the fact.

And, the fact is that:

: Today, many people, by laziness or ignorance, omit the accents and
: cedillas on uppercase characters.

> believe this entire issue is completely unrelated to

See your subject.

Thank you again to have strengthened the fact you stated.

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 23:13:22 +0900

> How the locale information could be supplied?

Are there anyone who can propose some mechanism to provide
the necessary, at least for TLDs, locale information?

						Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Wed, 17 Nov 2010 23:52:56 +0900

> that really what we want to say?

Several months ago, I wrote:

: Isn't RFC1034 clear enough?
:    - A name error indicating that the name does not exist.  This
:      may include CNAME RRs that indicate that the original query
:      name was an alias for a name which does not exist.

to people, including you, who half-understand one of two very
fundamental DNS-related RFCs.

Some of the people are implementers.

Are you ready to withdraw your statement above?

Or?

					Masataka Ohta

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 17 Nov 2010 09:54:30 -0500

Morning Andrew,

On 11/16/10 9:53 AM, Andrew Sullivan wrote:

> ...  I was simply arguing
> write something that depends on it.

A reasonable observation. The responsibility to ensure that the 
nuances of dependency were correctly noted in the past, or are 
correctly noted in the present, remain. If only every "i" had been 
correctly crossed, every "t" correctly dotted...

> ... If one thinks that IDNA2008 is
> in light of that document.

Loosely speaking, there is something that superficially resembles an 
obligation, but there has been no structural presence of a protocol 
supporting organization on the ICANN Board since December, 2002, only 
non-voting liaisons, and up until the recent moment, NOMCOM selected 
voting members with general technical competencies, now more weighted 
to competencies other than technical. So organic to ICANN's decision 
making process, no such general obligation exists or is latent. 
Organic to its By-Laws, there is an obligation to consider advice from 
the GAC, could you point to an obligation to consider advice from any 
other body?

One could point to the "Standards" language in ICANN's various 
"Mission" documents and the IETF's "Standards Track" document series, 
but that does involve a significant passage of time, and timeliness 
appears to be relevant, and it is not clear that an enforceable 
contractual obligation arises from "mission" and "purpose" language.

The UniCadettes' TR46 is a "IDNA2008 Considered Harmful" document, not 
that I think it the best thinking on the subject, and it is hardly a 
secret that directionality leakage across label separators is a 
feature not desired, and ... There are major objections, such as TR46, 
and moderate objections such as the directionality properties of "." 
and non-separator repertoire character properties, which vary from 
minor nits to moderate (fixable) objections, such as those which 
rfc4317 addressed.

   The IETF is about protocol, and all this
> understood somewhere as a protocol restriction.

Intent is good. Details matter. i's and t's.

> alphabetic.  Therefore, not allowed.  ...

I've written a separate note on those issues.

> ... If someone at ICANN wants to
> change that, s/he will need to write a draft.

There's not that large a qualified labor pool there to author such a 
document, and there may be non-technical impediments to ordinary 
contributions as we know them, a property more generally true than I'd 
like -- I still recall one exit interview marked by reference to a I-D 
I'd written on parallelism, file systems, and name spaces.

> ... Or, of course, ignore

There are a lot of RFCs that are ignored, as is the ITU-T. These are 
not relevant to the issues at hand. I think your final line falls 
under the heading "rhetorical excess" and is best ignored.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Nov 2010 11:45:55 -0500

This is on dnsop, but just to be clear: for this and all the other
messages I've sent in this thread, no hat.

On Thu, Nov 18, 2010 at 12:08:13AM +1100, James Mitchell wrote:

> Do we really want to say to 3com (probably a bad example, but go
> with the concept) that they cannot have a TLD when their competitors
> can? 

That is None Of Our Business.

What this draft does is expand the previous rules about TLDs in the
DNS in the absolute minimum way necessary to allow new TLDs using
IDNA2008.  It won't allow every possible TLD, in exactly the way that
every possible LDH TLD is maybe or maybe not permitted by the RFC.

The only avenue open to people who think this draft should not be
published is to claim that the "will be alphabetic" claim in RFC1123
is not and never was an assertion to the rest of the network about
what assumptions they might legitimately make about TLDs.  In other
words, you have to argue that the assertion "will be alphabetic" was
(only) a statement of policy in force at the time; that such policy
was clearly defeasible; and that the policy has been quite plainly
overtaken by a new policy as determined by the relevant policy makers.
I'm actually mostly comfortable with such an argument, but there are
plenty of people who aren't.  I say "mostly" because I don't think the
policy people at ICANN have made anything about this topic even
remotely clear, including that they think they are changing a rule in
RFC 1123 and that they're doing it deliberately.  (This is not to
attack ICANN: they have their own problems, and I'm sympathetic.)
Note that some people in this thread are making that argument quite
clearly; I think it's an entirely reasonable position to take, though
I don't happen to share it.

If you think that we do in fact need an update to 1123 to clarify
things, then there is nothing at all wrong with publishing this
document right now, in order to allow the minimum necessary, and then
revisiting the question more completely (ideally, suggesting to ICANN
participants or staff that clear claims about the boundary between
policy and protocol here from their quarter would also be useful,
recognizing that there will be some disagreements and need to work
things out).

When 1123 was written, the Internet was in the early phases of the
commercial explosion.  We're past that now, and conditions are
obviously different.  But we have to deal with the fact that we have a
deployed system with a lot of different things dependent on the
historical behaviour.  Part of our responsibility, _particularly_ in
the operations end of the IETF "technical community", is to recommend
prudent and cautious development of the operational conventions on the
network: the line between policy and protocol has not always been
bright.  The closer we get to the thing that everyone depends on (and
the contents of the root zone are surely within spitting of
"everyone"), the more conservative we have to be.  And yes, that
sometimes means that we need to recommend prudence even if it isn't
desirable to particular interests.

> As a thought, consider names written in the Arabic script. Being a
> cursive script, how is a TLD applicant expected to separate 'words'
> in a top level domain without the use of a hyphen or
> equivalent.

They already have a problem, because DNS labels aren't words.  They're
mnemonics, perhaps, but not words.  The publisher, O'Reilly, isn't
going to be able to get .o'reilly either, no matter what we do: it's
not allowed by the traditional LDH rule and it doesn't fall under
IDNA2008.  Is this discrimination?  Only in the traditional meaning of
"applying correct discernment", I say.

Regards,

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 17 Nov 2010 13:00:13 -0500

On 11/17/10 11:45 AM, Andrew Sullivan wrote:
> On Thu, Nov 18, 2010 at 12:08:13AM +1100, (someone) wrote:
...
>> As a thought, consider names written in the Arabic script...

Throw away comments arising from a lack of subject matter expertise 
should not be offered. There is at least one list for discussion of 
script issues in label composition and dnsop isn't it.

Eric

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Nov 2010 14:04:11 -0500

On Wed, Nov 17, 2010 at 09:54:30AM -0500, Eric Brunner-Williams wrote:

> A reasonable observation. The responsibility to ensure that the nuances 
> of dependency were correctly noted in the past, or are correctly noted in 
> the present, remain. If only every "i" had been correctly crossed, every 
> "t" correctly dotted...

If that's the issue, then we're in very deep water indeed.  RFCs 1034
and 1035 are not without ambiguity.

> obligation

I meant it in the simple sense that, given that they're the people
making the policies, they have the responsibility to do certain work.
It's only that sort of implicit obligation, and I'll cheerfully (well,
glumly, but I'm not exactly Tigger) concede that legal ones are
probably not there.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 17 Nov 2010 14:39:53 -0500

> glumly, but I'm not exactly Tigger) concede that legal ones are

I tried to make the point that specific competency matters when 
offering a comment on the proposal to reform or abolish the Technical 
Liaison Group.

The authors of that proposal did something I've never encountered in 
all my years of ICANN participation, they contacted me because I 
didn't agree with them, and asked questions. The paragraph in the note 
you've responded to on the obligation ICANN has to gracefully, or 
gracelessly, accept clue-by-fours, absent any participation on its 
Board since the 2002 by-laws change, was written reflecting my 
thoughts on the problem of specific competency and responsibility when 
only an advisory or incidental decision making standing exists.

The URL for public comments is: 
http://forum.icann.org/lists/tlg-review-2010/

And I suspect gloomy old Eeyore is more on-point than cheerful and 
bouncy Tigger.

Eric

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 22:15:58 +0100

On Wed, Nov 17, 2010 at 11:15:04PM +1100,
 Mark Andrews <[email-masked]> wrote 

> Except there are plenty of applications that don't do this so it is 

I do not really see what conclusion you draw from that fact. Yes,
there are broken applications, I do not doubt it. There are probably
apps that try to resolve a domain name without checking before that it
is not an IP address, hereby violating RFC 1123. These apps will have
problems if ICANN delegates .NNN where NNN is a number.

But it does not imply that we should hardwire the no-digits rule in
a RFC. For two reasons:

1) There are applications that violate RFC 5322 (typically email
syntax checkers on Web pages, which reject many valid RFC 5322
addresses). Yet, we do not modify RFC 5322 to align it on these apps. 

2) It may be a wise policy for ICANN to refuse the delegation of
all-digits TLDs. But it is a policy issue, similar to registries (most
TLD do so) which delegates only LDH domains (when the DNS would accept
other names). There is zero technical reason to write down this limit
in a RFC about the syntax.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 17 Nov 2010 22:24:30 +0100

On Wed, Nov 17, 2010 at 11:45:55AM -0500,
 Andrew Sullivan <[email-masked]> wrote 
 a message of 81 lines which said:

> what assumptions they might legitimately make about TLDs.

Correct.

> document right now, in order to allow the minimum necessary, and
> then revisiting the question more completely

Then I disagree: currently, nothing really forbids TLD-with-digits
such as .3com or .fun4u If we publish draft-liman-tld-names-04 as it
is, then the issue will be seen by many as settled and people will say
"See, TLD-with-digits are forbidden by IETF" (when, today, people who
dislike TLD-with-digits have to create their own policy). It will be
much more difficult to change it after that.

Note that there is no emergency for this document: it was supposed to
be necessary for IDN TLD but, as we all saw, IDN TLD were created,
proving that the entire issue of "RFC 1123 disallows it" was purely
political.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 18 Nov 2010 10:51:20 +1100

In message <[email-masked]>, Stephane Bortzmeyer writes:
> there are broken applications, I do not doubt it.

Actually they are not broken.  Only if you want to support IPv4
literals do you need to check.  The rules in RFC 1123 are designed
to prevent accidental matches when you only want to accept domain
names.

dig is a example of a application that does not check for IPv4
addresses as it is only expecting domain names.  If you want it to
treat the input as a address you have to explicitly tell so.

RFC 952 label rules prevented IPv4 address from ever being matched
even when searching because no label could match a address component.
The two were in different namespaces.  IPv4 address components all
start with a digit in all the forms of IPv4 address that I'm aware
of.  No hostname label could start with a digit.  Two disjoint sets.

RFC 1123 relaxed RFC 952 label rules but attempted to prevent
accidental matches in the multiple label case by assuming that
searches would not occur with multiple labels and by ensuring that
at least one of the labels, the last, would not be a valid address
component.

I would be quite happy to relax TLD labels so that they matched the
unmodified RFC 952 label and to explictly state that TLD labels
starting with a digit are prohibited to prevent accidental matches
against IPv4 address components.

> There are probably

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 18 Nov 2010 10:43:45 +0100

> As a thought, consider names written in the Arabic script. Being a cursive script, how is a TLD applicant expected to separate 'words' in a top level domain without the use of a hyphen or equivalen…

FWIW: This is a completely false statement.

Can we stay at discussing the draft please?

   Patrik

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 18 Nov 2010 21:55:02 +0900

James Mitchell wrote:

> As a thought, consider names written in the Arabic script.

Arabic? Isn't Latin/French localization much more than enough
to show IDNs are not operational.

If not...

> Being
> a cursive script, how is a TLD applicant expected to separate
> 'words' in a top level domain without the use of a hyphen or
> equivalent.

> Removing the spaces will cause the characters to join, and the
> meaning lost (besides which the A-label will contain hyphens
> anyway?!).

> I'm far from qualified to talk authoritatively on the Arabic
> script, or how it will be used in domain names, however I do
> know of parties that will be applying for Arabic TLDs - are
> we to exclude these applicants?

As is explained in wikipedia

   http://en.wikipedia.org/wiki/Arabic_alphabet

arabic letters have four forms, "isolated", "end", "middle"
and "beggining" and the form is determined by the location
of a letter within a word. Thus, they are not different
from Latin distinctions of capital/small letters, which is
determined by the location of a letter within a sentence.

So, it is an extended case insensitivity problem actively
ignored by people working on Unicode.

Moreover, as the wikipedia entry says:

   For compatibility with previous standards, all these forms can
   be encoded separately in Unicode; however, they can also be
   inferred from their joining context, using the same encoding.
   The following table shows this common encoding, in addition to
   the compatibility encodings for their normally contextual
   forms (Arabic texts should be encoded today using only the
   common encoding, but the rendering must then infer the joining
   types to determine the correct glyph forms, with or without
   ligation).

while separate code points of Unicode are used between different
forms, extended case insensitivity between forms of Arabic
characters is not specified at all.

The situation is even more confusing than Latin/French, which
is why I wrote:

It is trivially easy to declare some broken specification as
IDN 2008 or something like that, but it does not make localized
domain names operational.

						Masataka Oh

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 18 Nov 2010 09:07:29 -0500

> determined by the location of a letter within a sentence.

I don't see how any of the above (or any of the rest of the message,
which I clipped but which betrays a misunderstanding of nuances of
writing systems more or less as complete as the misunderstanding
demonstrated above) has anything at all to do with the current draft.
I think Ohta-san has made it clear that he thinks IDNA is broken.
Point noted.  But there's a whole list devoted to the topic of IDNA,
and I don't believe it's in scope for this draft.  The draft accepts
IDNA as a foundation, and proceeds from there.  IDNA2008 is a standards
track IETF project, and it is therefore legitimate for an I-D to start
with that specification as a starting point.

If one thinks the standards track IDNA2008 specification is wrong or
won't work (I suggested this before), one can go write a draft that
says so.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 18 Nov 2010 11:20:10 -0500

>>     http://en.wikipedia.org/wiki/Arabic_alphabet

it really is amusing to find this form of cite in a specifications 
discussion.

in the off chance that anyone actually is curious, and has no real 
knowledge of arabic, and would like an intro to clue, i recommend 
spending a pleasant 27 minutes watching thomas milo discuss arabic 
typography.

-e

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 18 Nov 2010 11:38:23 -0500

i suppose a url would be helpful.

http://river-valley.tv/media/conferences/arabic_typography_2008/thomas-milo/

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Nov 2010 07:51:04 +0900

> Point noted.  But there's a whole list devoted to the topic of IDNA,

That's not an appropriate topic to be discussed further here
and, perhaps, not in IDNA list.

Instead, DNS operational problems caused by insufficient support
for (extended) case insensitivity or canonicalization are
discussed.

I showed examples of Latin characters for French because it
should be much more familiar to most of you than Chinese or
Arabic ones.

An operational requirement for multiple identical zones,
names of which are not canonicalized by IDNA, is zone
synchronization, for which exponentially many BNAME RR, which
does not exist, is required, which is a problem.

Another operational problem is exponentially many signatures,
which is huge, required for DNSSEC.

Unless we accept exponentially many BNAME RRs (and abandon
DNSSEC, which I recommend anyway), IDNA2008 must be revised,
details of which I am not interested in.

> and I don't believe it's in scope for this draft.

As for the draft, as some non-ASCII name wrote, locale
information is necessary to properly handle case
insensitivity of Latin/French. And it is necessary at
least for TLDs, which makes publishing of the draft should
be delayed until details of IDNA revision is available.

					Masataka Ohta

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Nov 2010 08:05:18 +0900

Eric Brunner-Williams wrote:

> i recommend

If it's just a reference, that's fine. But, if you want to
make some point, make it with your own words or quotation,
not just a reference to lengthy video, please.

Anyway, Arabic strings are examples of exponential explosions
with large coefficients a lot easier to understand for most
of you than Chinese ones.

> it really is amusing to find this form of cite in a specifications

I have no problem to refer and quote English wikipedia to express
my prior knowledge obtained in Japanese, because it is a lot
easier than translating technical terms by myself.

						Masataka Ohta

---

From: Eric Brunner-Williams <[email-masked]>
Date: Thu, 18 Nov 2010 19:35:51 -0500

> not just a reference to lengthy video, please.

noted.

> of you than Chinese ones.

the density of variant (context dependent) characters in arabic 
script, whether sampled as text, or sampled as domain names, is 
sparse, relative to the density of "variant" characters in the 
(unified) han script(s), which is not quite 2^^n, where n is the 
number of characters in a label, but is sufficiently close to allow 
the "exponential" term to be reasonably used.

i know this to be the case, but just in case the point was not 
appreciated by the icann*, and other ietf persons present** at the idn 
session during the icann brussels meeting, i carefully asked the 
density question of the presenters, one a han script (chinese) domain 
name registry operator, the other an arabic script (arabic) domain 
name registry operator. their answers were as i expected, and fail to 
support a "Arabic strings are examples of exponential explosions with 
large coefficients" claim.

variants in arabic script present problems to the idn(a) 
specification(s) that assume "unicode" as the character repertoire, 
but they are unlike in scale the problems presented sc/tc equivalence 
classes presented with similar conditions and assumptions.

-e

*  t. dam
** o. gudmundsson

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 19 Nov 2010 16:43:46 +0900

Eric Brunner-Williams wrote:

> the density of variant (context dependent) characters in arabic script, 
> whether sampled as text, or sampled as domain names, is sparse,

While meaningful variations would be sparse, meaningful
capitalization of Latin is also sparse. That is, meaningful
capitalization of "mydomain" should be

	myDomain
	Mydomain
	MyDomain
	MYDOMAIN

However, meaningless capitalization such as:

	mYdOmAiN

should also be protected, which should be same for Arabic.

A protection could be rejection of domain registration. But it,
anyway, requires a document of complete and unambiguous
definition of extended case insensitivities.

And, the definition used for TLDs must be international one.

So, the requirement for complete and unambiguous specification
for case insensitivities or canonicalization is same.

> relative
> to the density of "variant" characters in the (unified) han script(s), 
> which is not quite 2^^n,

You seems to be thinking "variant" for Chinese mean simplified
and complex. But there are other types of "variant" Chinese
characters. It's somewhat like plain 'C' without ceddille and
'C' with ceddille, which, sometimes (here is dependency on
locale information), must be treated as identical characters.

> their answers were as i expected, and fail to support a
> "Arabic strings are examples of exponential explosions with

They should, naturally, reject meaningless combinations.

						Masataka Ohta

---

From: Eric Brunner-Williams <[email-masked]>
Date: Fri, 19 Nov 2010 07:34:23 -0500

> definition of extended case insensitivities.

as a sometime registry operator, i'm only mildly curious as to the 
registration policies of other registry operators. the range of values 
preferred by a data base operator is distinct from the range of values 
possible in a data type, and the later is amenable to agreement among 
implementers.

> And, the definition used for TLDs must be international one.

while this sounds nice, in practice it means that the operators of the 
two constellations of name servers that support two mostly identical 
views of "." must agree, and from november 2001 to the very recent 
present, there was a substantial area of disagreement between these 
two operator communities over a charset issue. this is probably not a 
feature to be accidentally aggravated by an insistence on a single, 
and possibly incomplete, policy model, or indifference to the 
perception of genuine necessity by one, or the other, of the operators.

> for case insensitivities or canonicalization is same.

case is a property of a particular character repertoire, preexisting 
digital encoding methods.

canonicalization in the sense used in i18n contexts where variable 
length encodings allow for two or more possible encodings for one or 
more characters in some character repertoire, and meaningless in fixed 
length encoded contexts, results in fewer, and possibly a single 
choice of possible encodings of characters, and therefore of sequences 
of multiply encoded characters. it is a property of variable length 
encodings, not of encodings generally, or of character repertoires, or 
scripts.

it is unlikely that a property preexisting encodings, and a property 
of specific encodings, are correctly specified without distinction.

> characters.

the density of true variant characters in (unified) han script,
whether sampled as text, or sampled as domain names, is also sparse, 
relative to the density of "variant" characters in the (unified) han 
script(s), which is not quite 2^^n, where n is the number of 
characters in a label, but is sufficiently close to allow the 
"exponential" term to be reasonably used.

quoting my previous note's concluding para with only the following 
change: s/arabic/(unified) han/

"variants in arabic script present problems to the idn(a) 
specification(s) that assume "unicode" as the character repertoire, 
but they are unlike in scale the problems presented sc/tc equivalence 
classes presented with similar conditions and assumptions."

  It's somewhat like plain 'C' without ceddille and
> They should, naturally, reject meaningless combinations.

i think the fundamental issue here is not to accept meaningless, or 
meaning-loosing reasonings by imagined similarity. case is not a 
property of han script(s). when non-specialists imagine that han 
script(s) have a case-like property and then try to reason about han 
script(s), error arises.

there are interesting issues in computerized typography, of arabic 
script, and other scripts, with, and without, specific encoding 
properties, and with, and without, the issue domain being specific to 
an application domain, such as dns labels.

-e

---

From: Doug Barton <[email-masked]>
Date: Sun, 21 Nov 2010 19:53:38 -0800

On 11/17/2010 01:19, Stephane Bortzmeyer wrote:
| On Thu, Nov 11, 2010 at 01:42:24PM -0500,
|   Joe Abley<[email-masked]>  wrote
|   a message of 15 lines which said:
|
|> http://www.ietf.org/id/draft-liman-tld-names-04.txt
|>
|> is the latest iteration of an effort started quite some time ago to
|> clarify the somewhat vague inference in RFC 1123 and create a more
|> precise specification for the syntax of TLD labels in the DNS.
|
| Nice attempt but, as I have already said
| <http://www.ietf.org/mail-archive/web/dnsop/current/msg07058.html>,
| there is zero technical reason to limit the TLD to alphabetic
| characters and therefore, the rule:
|
| traditional-tld-label = 1*63(ALPHA)
|
| is both a new rule (it was not in RFC 1034 or 1035) and a bad one.
|
| I object to the creation of new rules disguised as clarifications.

Fully agree with Stephane on this. That bit needs to be changed to the
ABNF equivalent of the same LDH rules we use for hostnames. I've also
attached a diff with some related edits. More importantly it's worth
correcting the IANA section to make it clear that the IANA does not
create policy.

To amplify my agreement with Stephane, we have already added LDH labels
to the top level, and the sky did not fall. Therefore the only valid
clarification from a _technical_ perspective is that the aside in 1123
was never a protocol restriction. Anything else is layer 9, and
specifically not our problem.

I also agree with Stephane and Andrew that there are poorly written
programs in the world that will have problems with TLD names that start
with a non-alphabetic. We already lived through the drama that new TLDs
caused 10 years ago (been there, done that), and I agree with Stephane
that whatever drama ensues from a TLD that starts with a digit is
unlikely to cause the network to melt down tomorrow.

Doug

- -- 

	Nothin' ever doesn't change, but nothin' changes much.
			-- OK Go

	Breadth of IT experience, and depth of knowledge in the DNS.
	Yours for the right price.  :)  http://SupersetSolutions.com/

--- draft-liman-tld-names-04-orig.txt	2010-11-21 18:51:33.000000000 -0800
+++ draft-liman-tld-names-04.txt	2010-11-21 19:30:48.000000000 -0800
@@ -255,24 +255,24 @@
       #.#.#.#, since at least the highest-level component label will be
       alphabetic.'  [Section 2.1]
 
-   Some implementers may have understood the above phrase 'will be
+   Some implementers may have incorrectly understood the above phrase 'will be
    alphabetic' to be a protocol restriction.
 
    Neither [RFC0952] nor [RFC1123] explicitly states the reasons for
    these restrictions.  It might be supposed that human factors were a
    consideration; [RFC1123] appears to suggest that one of the reasons
    was to prevent confusion between dotted-decimal IPv4 addresses and
-   host domain names.  In any case, it is reasonable to believe that the
-   restrictions have been assumed in some deployed software, and that
-   changes to the rules should be undertaken with caution.
+   host domain names.
 
    The Internationalised Domain Names in Applications 2008 specification
    (IDNA2008) [RFC5891] [RFC5892] provides a protocol for encoding
    Unicode strings in DNS-Labels.  The Unicode string used by
    applications is known as a U-Label; its corresponding encoding in the
-   DNS is known as an A-Label.  The terms A-Label and U-Label are used
-   in this document as defined in [RFC5890].  Valid A-Labels always
-   contain non-alphabetic characters.
+   DNS is known as an A-Label.  
+   In addition to alphabetics valid A-Labels may contain
+   digits and always contain the minus sign. For example at the time
+   of this writing XN--P1AI is the Country-code top-level domain
+   designated for Russian Federation.

@@ -454,7 +454,7 @@
    While this document makes no requests of the IANA, management of the
    root zone is an IANA function.  This document expands the set of
    strings permitted for delegation from the root zone, and hence
-   establishes new limits for the corresponding IANA policy.
+   establishes new limits for the corresponding IANA procedures.

---

From: Masataka Ohta <[email-masked]>
Date: Mon, 22 Nov 2010 14:14:00 +0900

With the original subject, let's discuss examples with Latin
characters only.

> meaning-loosing reasonings by imagined similarity.

Unless the reasonings are formerly described, it is impossible
to operate international zones, especially root zones.

Note also that, just as a meaningless label

	aaaaaaaaaaaaaaaaaaaa

is accepted today, a label with 20 characters of 'y' with dieaeresis
will be acceptable, which causes exponential explosion.

> case is not a

Beyond simple case but still within ASCII, how about Dutch
example where "IJ" and 'Y' are equivalent?

Is a label

	YYY

equivalent to

	IJIJIJ

?

This case should be resolved in a way compatible to the current
rules for ASCII-only labels.

But, we do need precise definitions on character/string
equivalences.

> while this sounds nice, in practice it means that the operators
> of the two constellations of name servers that support two
> mostly identical views of "." must agree,

Not necessarily.

An international definition could be a transitive closure of
equivalences of all the possible locales.

> and from november
> 2001 to the very recent present, there was a substantial
> area of disagreement between these two operator communities
> over a charset issue.

I don't know what is the disagreement but I know it is not
an issued to be resolved here.

						Masataka Ohta

---

From: Joe Abley <[email-masked]>
Date: Mon, 22 Nov 2010 09:30:34 -0500

> correcting the IANA section to make it clear that the IANA does not

Thanks for your review (Stéphane and Doug), and sorry for not replying to your comments earlier, Stéphane.

I also know of no protocol (1034/1035) restriction for labels in the root zone. However, as the document describes in citations from 1123 there is some degree of expectation that top-level domain labels have additional technical policy restrictions.

I don't know that we have the institutional knowledge to fully understand the "alphabetic" reference in 1123, and to my knowledge we don't have any consolidated, rigourous field experience of what software exists that might assume that a label which is not "alphabetic" is something other than a component of a domain name.

I'll note (a) that there has never existed a US-ASCII (i.e. non-IDNA2008) TLD label that has *not* been "alphabetic", so we have no deployed examples in the namespace from which to infer stability, and (b) the software we might be concerned about is application-layer stuff, really anything that might ever need to process a domain name, and hence there's a lot of it and it's hard to catalogue.

The conservative path seems to be to assume that there is deployed software that relies on the same expectation expressed loosely in 1123. In that context, the goal of this document really is to clarify the situation and eliminate the ambiguity.

I am carefully not expressing a personal opinion about whether the technical policy restrictions on TLD labels should change from the conservative interpretation of what they are today (per above). No doubt a future document, citing a wealth of research and experimental data, could successfully update this document and relax the restriction.

I'll offer an opinion that doing that work now is the wrong thing, however. Clarifying the existing technical policy is something that I think we ought to be able to do quickly and easily now; changing it is likely to be far more contentious and hence if it succeeds at all will take far more time.

The community is best served by the existence of clear, unambiguous specifications. Clarify then extend will result in a near-immediate clear specification; extend alone will take much longer, and may never produce anything at all.

Joe

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Nov 2010 14:44:44 -0800

On 11/22/2010 06:30, Joe Abley wrote:

> Thanks for your review (Stéphane and Doug), and sorry for not
> replying to your comments earlier, Stéphane.
>
> I also know of no protocol (1034/1035) restriction for labels in the
> root zone. However, as the document describes in citations from 1123
> there is some degree of expectation that top-level domain labels have
> additional technical policy restrictions.

I don't think you can mix those 2 terms in the same sentence. :)  I 
definitely don't think you _should_ mix the 2 concepts in this document.

> I don't know that we have the institutional knowledge to fully
> understand the "alphabetic" reference in 1123,

Arguable, but let's take your premise. Given the world in which we don't 
know exactly what the authors were referring to, in a document that is 
well formatted to clearly delineate the protocol elements from the 
background, IMO what you're attempting to do is ADD a protocol 
restriction where one did not exist previously. That's just plain wrong, 
on several levels.

> and to my knowledge we
> don't have any consolidated, rigourous field experience of what
> software exists that might assume that a label which is not
> "alphabetic" is something other than a component of a domain name.

I'll go you one better. I'm 100% sure that there is deployed software 
that WILL break if you have a TLD label that even starts with a number, 
never mind is all-numeric (I think Andrew did an admirable job of 
explaining this, I won't bother repeating his explanation). But I don't 
care. That isn't a protocol issue, and it's only an operational issue as 
a secondary effect. We already saw this movie in 2001, and we've all 
lived to tell the tale. (I'm assuming that I don't need to remind the 
list of all the excitement created by TLD labels with more than 3 
characters, but I'm happy to if needs be.)

> I'll note (a) that there has never existed a US-ASCII (i.e.
> non-IDNA2008) TLD label that has *not* been "alphabetic", so we have
> no deployed examples in the namespace from which to infer stability,

I'm not sure why you think that distinction (A-label vs. gTLD label) is 
relevant.

> (b) the software we might be concerned about is application-layer
> stuff, really anything that might ever need to process a domain name,
> and hence there's a lot of it and it's hard to catalogue.

Already stipulated, and again, so what? At best this issue warrants a 
paragraph in your draft advising potential new-new-new-TLD applicants 
that this issue exists. I actually considered drafting such a thing (and 
am still willing to do so if there is interest) but I did not because I 
don't think that it belongs in your draft, I think it should be part of 
the policy process.

In fact, if I were to go into full-blown evil genius mode I would say 
that you should _not_ advertise this problem, and fail any applicant for 
a string that contains a digit which does not specifically address the 
issue in their application. But I digress ....

> The conservative path seems to be to assume that there is deployed
> software that relies on the same expectation expressed loosely in
> 1123. In that context, the goal of this document really is to clarify
> the situation and eliminate the ambiguity.

Once again, that's a _policy_ issue, not a technical one. There is no 
_technical_ reason that a TLD label cannot contain, or even begin with a 
digit, and _we_ should not be imposing one. Applicants for new TLDs that 
contain a digit should be informed of the issue, and realize what they 
are getting themselves into.

> I am carefully not expressing a personal opinion about whether the
> technical policy restrictions on TLD labels should change from the
> conservative interpretation of what they are today (per above). No
> doubt a future document, citing a wealth of research and experimental
> data, could successfully update this document and relax the
> restriction.

You have that wrong way around. There is no "technical policy 
restriction" today, you're attempting to assert one, and use the 
"clarification" process to cement your assertion. I object to this in 
the strongest possible terms.

If you/ICANN believes that there _should_ be a technical restriction of 
this nature it's up to you/ICANN to produce a document with a wealth of 
research and experimental data saying so; then let the community decide 
how to proceed. Meanwhile, stop trying to shoehorn policy issues into 
the technical space.

And that's not a snark, I'm quite serious about this. I've sat on both 
sides of the aisle (policy and technical) and just in case there is 
anyone who doesn't already know, in the interests of full disclosure I 
used to be an ICANN staff member. I realize that there are numerous 
"issues" about new TLDs in the ICANN world, and I've been in a position 
similar to the one Joe is in now. It's not fun, I don't envy him, and 
hopefully he realizes that nothing I'm saying is personally directed at 
him. But the advantage of being where I am now is that I get to speak my 
mind, and lob the policy ball back into ICANN's court. I can just 
imagine the ICANN open forum where someone asks, "But WHY can't we have 
TLDs with digits in them?" "Because the IETF says so. Next question?" I 
really do not want to go there.

Doug

--

---

From: Joe Abley <[email-masked]>
Date: Tue, 23 Nov 2010 19:19:37 -0500

On 2010-11-23, at 17:44, Doug Barton wrote:

> I don't think you can mix those 2 terms in the same sentence. :)

Just so I understand the context for your comments, you're saying that in your opinion:

1. there is no restriction to be inferred from RFC 1123 that TLD labels be alphabetic;

2. it is better for deployed software to break than for the IETF to involve itself in anything resembling policy.

Did I get that right?

Joe

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Nov 2010 17:26:29 -0800

> 1. there is no restriction to be inferred from RFC 1123 that TLD

Unqualified "yes" to this.

> 2. it is better for deployed software to break than for the IETF to
> involve itself in anything resembling policy.

A qualified "yes" here. I'm saying that in _this_ situation, the IETF 
does not and should not have a policy role, and should limit its 
commentary to the technical. There is (rather obviously at this point) 
no _technical_ reason that TLD labels should be all-alphabetic. 
Therefore the IETF should not say that there is.

Furthermore I am saying that the benefits of keeping the TLD namespace 
open to all technically possible values outweigh the costs. Look at what 
happened in 2001. Many people said that the sky would fall when we 
introduced TLD labels of more than 3 characters. The relevant players 
all said "We know that there are potholes on this road, but we want to 
travel it anyway." The actual experience turned out to be rougher than 
some expected it to be, but we got through it. The same thing is going 
to happen here, without question. But to once again summarize my points:
1. I think the benefits are worth it
2. I DO NOT think it's the IETF's role to tell people that they can't do it
3. I DO NOT even think it's ICANN's role to tell them that they should 
not or cannot do it.

That said, I DO think that there IS a policy role for ICANN here, and 
while I don't want to rathole that in this forum I think that gTLD 
applicants for such strings should be fully advised of the problems, and 
I think that there should be some extra-ordinary measures put in place 
to safeguard registrants in any theoretical new TLD that falls into this 
category. But once again, those are ICANNs of worms. :)

hth,

Doug

--

---

From: Joe Abley <[email-masked]>
Date: Tue, 23 Nov 2010 20:35:08 -0500

> Unqualified "yes" to this.

I presume you appreciate that not everybody shares your opinion on this.

> A qualified "yes" here. I'm saying that in _this_ situation, the IETF does not and should not have a policy role, and should limit its commentary to the technical. There is (rather obviously at this point) no _technical_ reason that TLD labels should be all-alphabetic.

Well, beyond the expectation in deployed software this should be the case. That's an operational consideration that I think is reasonable to describe as technical.

> Furthermore I am saying that the benefits of keeping the TLD namespace open to all technically possible values outweigh the costs. [...]

I thought you weren't interested in discussing policy in the IETF? :-)

Joe

---

From: James Mitchell <[email-masked]>
Date: Wed, 24 Nov 2010 13:15:23 +1100

If deployed software does not work with a TLD, it is the TLD owner who loses. ICANN makes it clear to applicants that the TLD may not function on the Internet (gTLD Applicant Guidebook, Proposed Final Version, Section 1.2.4, Notice concerning Technical Acceptance Issues with New gTLDs) and states that successful applicants 'may find themselves expending considerable efforts working with providers to achieve acceptance of their new top-level domain.'

The people responsible for the deployed software are under no obligation to make any changes.

James

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Joe
> Abley
> Sent: Wednesday, 24 November 2010 12:35 PM
> To: Doug Barton
> Cc: IETF DNSOP WG
> > A qualified "yes" here. I'm saying that in _this_ situation, the IETF does
> not and should not have a policy role, and should limit its commentary to the
> technical. There is (rather obviously at this point) no _technical_ reason
> that TLD labels should be all-alphabetic.
> 
> Well, beyond the expectation in deployed software this should be the case.
> That's an operational consideration that I think is reasonable to describe as
> technical.
> 
> > Furthermore I am saying that the benefits of keeping the TLD namespace open
> to all technically possible values outweigh the costs. [...]
>

---

From: Doug Barton <[email-masked]>
Date: Tue, 23 Nov 2010 18:16:09 -0800

> I presume you appreciate that not everybody shares your opinion on

Hence the word "incorrectly" in the diff I supplied.

It's also probably worth pointing out that I have been diligently trying 
to avoid the even-more-painful rathole of attempting to forensically 
determine the true meaning and intent behind the words. That said I have 
fairly strong suspicions with pretty good foundations that I understand 
why it was written the way it was, and I _still_ don't agree that the 
document, as written, defines a protocol restriction.

One could also travel down the more-painful-still rathole of things like 
'confirmation bias' that motivate people to see "evidence" of what they 
have always believed to be true even when it isn't there, but I'm pretty 
sure we don't want to go there.

>>> 2. it is better for deployed software to break than for the IETF
>>> to involve itself in anything resembling policy.
>>
>> A qualified "yes" here. I'm saying that in _this_ situation, the
>> IETF does not and should not have a policy role, and should limit
>> its commentary to the technical. There is (rather obviously at this
>> point) no _technical_ reason that TLD labels should be
>> all-alphabetic.
>
> Well, beyond the expectation in deployed software this should be the
> case. That's an operational consideration that I think is reasonable
> to describe as technical.

... which is why I'm willing to compromise as far as including a "Here 
be dragons" in your draft. But you could reductio this argument all the 
way down to not doing IDN TLDs at all, and solve the whole problem. For 
that matter, >3 character TLDs were clearly a mistake. Do you want to 
tell Cary that his delegation has been revoked, or should I?

The "deployed software will break" argument can be used as a reason not 
to do anything you choose to apply it to, especially in DNS. But whether 
it's worth it or not is a policy question. I'll say it one (hopefully) 
last time. There is no _technical_ reason why TLD strings cannot include 
digits, and the IETF should not say that there is.

>> Furthermore I am saying that the benefits of keeping the TLD
>> namespace open to all technically possible values outweigh the
>> costs. [...]
>

Doug (... and I'd have gotten away with it too, if it weren't for you 
meddling kids!)

--

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 24 Nov 2010 11:50:09 +0100

On 24 nov 2010, at 02.26, Doug Barton wrote:

> no _technical_ reason that TLD labels should be all-alphabetic

FWIW, when you display internationalized domain names, and mixed RTL and LTR contexts (overall, in a label etc), you can get "interesting" results when characters that have not directionality (like numbers) are displayed adjacent to punctuation.

See http://stupid.domain.name/node/681 for an example.

   Patrik

---

From: Patrik Fältström <[email-masked]>
Date: Wed, 24 Nov 2010 11:51:26 +0100

On 24 nov 2010, at 03.15, James Mitchell wrote:

> If deployed software does not work with a TLD, it is the TLD owner who loses.

I would like to say that the registrants that buy domain names in that TLD are the ones that loose.

   Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 24 Nov 2010 07:19:25 -0500

> FWIW, when you display internationalized domain names, and mixed RTL and LTR contexts (overall, in a label etc), you can get "interesting" results when characters that have not directionality (like…

digits in the U0030..U0039 (latin script digits), U0660..U669 (arabic 
script arabic-indic digits) and U06F0..U06F9 (arabic script eastern 
arabic-indic digits) have directionality properties. i know this was a 
casual error and paf is caffine-free slovenia at the moment.

> See http://stupid.domain.name/node/681 for an example.

the example shows that the bidi algorithm used, correctly, if the 
sequence of encoded values is "text", incorrectly, if the sequence of 
encoded values is a dns label, render a directionality property of "."

restated, "." has a property which is dependent upon the 
directionality of the proximal character(s), according to the authors 
of the idn bidi algorithm. this may come as a surprise to applications 
that assume that "." is a separator, semantically unaffected by the 
properties of adjacent character(s).

the net of the unicadette usage advice to the dns weenies is don't put 
digits in identifiers, um, don't put digits in identifiers composed 
from characters with a rtl directionality property, um, don't mix 
scripts with differing directionality properties, at least, not in 
sight of dots or children, not because these are not "proper words" in 
(some language), the point of view advanced by an important, but 
mistaken on this point, group of arabic script and arabic language 
(but not arabic script and farsi/urdu/... language) users, but because 
Ox2E in US-ASCII, a standard published in 1963, has a property unknown 
to the the authors of that sequence of standards.

one could summarize the unicadette's point of view that the choice of 
"." as a label separator was an error in 952 and that ken, mary and 
jake blew it, but the real blame should go to jon who blew it in 921 
(required reading for the no-digits advacates). we're all lucky that 
820's use of 0x2E has not yet been discovered by the unicadettes.

-e

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 24 Nov 2010 09:23:03 -0500

> If deployed software does not work with a TLD, it is the TLD owner who loses. 

I'm sorry, but that claim is arrant nonsense.  We _all_ lose.  The
IETF is supposed to be about interoperability, and if stuff breaks
because we have decided, "We don't care lalalalalala I can't hear
you there isn't a problem," then we ought to be ashamed of ourselves.

I think Joe's pragmatic approach is the right one: document right now
that whatever the restrictions might historically have been, we are
quite explicitly going to permit at the very least one class of
labels.

If people feel strongly that in fact the TLD label restriction never
was there and should not be, then once this document is published you
all can go out and write the draft, "TLD label character restrictions
considered harmful", and pursue the publication of that as an RFC.  In
the meantime, we have at least a technical document that makes clear
that certain things are permitted.

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Wed, 24 Nov 2010 09:52:35 -0500

On 11/24/10 9:23 AM, Andrew Sullivan wrote:
> I'm sorry, but that claim is arrant nonsense.  We _all_ lose. ...

-1.

first, the likelihood of the string review failing to detect a 
"deployed software does not work with string" condition that is not an 
edge case, is not large, and the collection of evaluation processes 
documented [1] clearly anticipates failing a non-zero number of 
applications for non-technical, as well as technical reasons, some of 
which are difficult to find consensus as to the necessity and utility, 
e.g., v6 and dnssec as mandatory to implement, flavor and amount of 
continuity funding instrument, etc.

second, as paf observed, where the string is proposed as a label in 
any other context, e.g., as a non-root terminating component of a 
multi-label sequence, it is the parties with an interest in that name 
to address mapping, the parties with an interest in that specific 
resource, and no other party attempting any other possible act of 
resolution, possibly to the same resource (see the clone warz, in 
dnsext and elsewhere) that "loses".

less absolute claims would be helpful.

i was under-amused by the earlier "it is better for deployed software 
to break than ..." misstating of a reasonable engineering view on the 
cost of correctness and the "i resume you appreciate that ..." form of 
issue advocacy. that passes for acceptable social discourse on icann 
policy lists, and a whole lot worse. it is infra dig here.

-e

[1] http://www.icann.org/en/announcements/announcement-2-12nov10-en.htm

---

From: Doug Barton <[email-masked]>
Date: Wed, 24 Nov 2010 10:48:19 -0800

On 11/24/2010 06:23, Andrew Sullivan wrote:
> I'm sorry, but that claim is arrant nonsense.  We _all_ lose.

Which is why I mentioned specifically that I believe ICANN does have a 
policy role here, and that (knowing what we know now about what happened 
in 2001) there should be extra care taken in negotiating the registry 
agreements to make sure that the registrants are knowingly taking the 
risk along with the registry. But those are policy issues.

> The

I am rather specifically NOT claiming that there is no problem, and your 
attempt here to paint me (and others who agree with this view) as 
childish/foolish is a borderline ad hominem attack.

I will once again point out that if your criteria is "We can never 
deploy anything new in DNS because something in the installed base will 
break" then the issue with this draft is moot. We simply will not do 
IDNs at all, and therefore there is no need for the draft to clarify 
anything. Oh and btw, are you going to notify Jari and Ralph that we're 
closing down dnsext, or would you like me to do it?

I'm quite serious here. You are setting the bar impossibly high and 
using arguments that don't make sense if you follow them to their 
logical conclusion.

> that certain things are permitted.

I've already lodged this objection more than once, but since you have 
repeated your side again, I'll do the same. We do not have a protocol 
restriction now, and your attempt to assert one in a "clarify" draft is 
at best, bogus.

--

---

From: David Conrad <[email-masked]>
Date: Wed, 24 Nov 2010 11:25:53 -0800

Andrew,

> you there isn't a problem," then we ought to be ashamed of ourselves.

I don't think anyone is doing this, rather it is the normal situation of trying to strike a balance between 100% backwards compatibility (which limits future innovation) and ignoring the installed base (which breaks things).

> quite explicitly going to permit at the very least one class of

I would agree that it is important to document existing reality and hence believe the draft should move forward.

> that certain things are permitted.

+1

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Thu, 25 Nov 2010 10:23:20 +0900

>> FWIW, when you display internationalized domain names, and mixed RTL 
>> and LTR contexts (overall, in a label etc), you can get "interesting" 
>> results when characters that have not directionality (like numbers) 
>> are displayed adjacent to punctuation.

> encoded values is a dns label, render a directionality property of "."

The only way to handle bidi with *PLAIN* text, which is what
we use in UNIX command lines and DNS names, is to do it with
finite state.

Otherwise, you can't search, because search with push down
automaton is prohibitively inefficient, which means nested
directionality can not be supported.

I warned so about 20 years ago.

Then, bidi support with plain text is just simple. Characters
do not have any bidi property and are displayed right to left
in RTL lines and left to right in LRT lines (words are often
spelled backward).

However, as Unicode plain text includes control characters for
nested  bidi, and is not plain, its bidi support specification
is totally confused and is unusable to handle real plain text.

We can't move forward until we have character encoding
with rational support for bidi.

						Masataka Ohta

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Nov 2010 09:56:43 -0500

> childish/foolish is a borderline ad hominem attack.

You have claimed that there is not a technical problem here, but
"merely" a policy one.  I am arguing that, given that some people
apparently read 1123 differently than you do, we have a technical
problem in the narrowest meaning of that term, and that we therefore
ought to address it.

Also, if you're going to start throwing around complaints about
fallacies, you'll want to describe them correctly.  If you really
think I'm misdescribing your position, it's not an _ad hominem_
anyway.  It's a straw person.  Moreover, while we're talking about
fallacies . . .

> closing down dnsext, or would you like me to do it?

. . . this is just a slippery slope argument, and not a very good one.
Engineering decisions involve trade-offs.  It is quite correct that
there may well be deployed software that will break when exposed to
on-the-wire DNS top-level labels that don't strictly conform to the
RFC 1123 "alphabetic" description.  That doesn't mean that we don't
deploy such labels: it means we have to make a decision about whether
the feature is worth the potential cost.

I think it is, and I also think that the right thing to do is to
specify exactly what we are changing and how so that, if something
breaks, people have something they can read in order to understand
what is going on.

Moreover, the class of applications that might be using the heuristic
about the top-level labels extends far beyond just those things
actually talking to the DNS.  It's actually that class of software I
am most concerned about.  That's what makes me think it is worth
specifying first the smallest variation from historical practice that
we can specify while still permitting the new use.

> restriction now, and your attempt to assert one in a "clarify" draft is  

Well, I'm not attempting anything: I didn't write the draft.  But I
think the draft tries to say that the 1123 language may be interpreted
(by some) as entailing a restriction, not that there is in fact such a
restriction:

   Some implementers may have understood the above phrase 'will be
   alphabetic' to be a protocol restriction.

It seems to me that if you want to make clearer that the text of 1123
ought not to be so interpreted, you could send text to that effect.

A

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

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Nov 2010 17:37:08 +0000

> quite explicitly going to permit at the very least one class of

Yes, but I think that the document should make it abundantly clear that
this restriction arises from the TLD allocation policy (NOT the protocol)
and this policy is subject to change, as in the introduction of long TLDs
and IDNS TLDs.

Tony.

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 25 Nov 2010 12:52:47 -0500

> and this policy is subject to change, as in the introduction of long TLDs

So what aside from 

   It is carefully noted that the specification in this document is not
   the only factor in choosing suitable TLD DNS-Labels, and that many
   considerations external to the IETF are included in that wider
   policy.  See Section 5 for more discussion of policy considerations.

do you want?  It seems to me that those who don't like the document
aren't actually offering text that they'd like to see in the document.
(The exception to this of course are those who say the document should
not be published, period.)

A

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

---

From: Tony Finch <[email-masked]>
Date: Fri, 26 Nov 2010 16:53:34 +0000

On Thu, 25 Nov 2010, Andrew Sullivan wrote:

> So what aside from [...] do you want?

Something like this:

Abstract

This memo clarifies the syntax of top-level domain labels in the domain
name system as specified in RFC 1123, and how this syntax relates to the
allocationn policy for TLDs. It describes the current

[...blah...]

Background

[RFC0952] defines a host name in the first paragraph under "ASSUMPTIONS",
as follows:

      A "name" ... is a text string up to 24 characters drawn from the
      alphabet (A-Z), digits (0-9), minus sign (-), and period (.).
      Note that periods are only allowed when they serve to delimit
      components of "domain style names".  (See RFC-921, "Domain Name
      System Implementation Schedule", for background).  No blank or
      space characters are permitted as part of a name.  No distinction
      is made between upper and lower case.  The first character must be
      an alpha character.  The last character must not be a minus sign
      or period.

[RFC1123] section 2.1 reaffirms this definition, but makes one change
to the syntax:

      The syntax of a legal Internet host name was specified in RFC-952
      [DNS:4].  One aspect of host name syntax is hereby changed: the
      restriction on the first character is relaxed to allow either a
      letter or a digit.  Host software MUST support this more liberal
      syntax.

In addition, the DISCUSSION in Section 2.1 says:

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

Some implementers may have understood the above phrase "will be
alphabetic" to be a protocol restriction. This is incorrect. It is in fact
a description of the TLD allocation policy at that time.

The TLD allocation policy has since had two significant syntactic changes.

On 16 November 2000 the first long TLD (.museum) was allocated, and it
was added to the root zone in June 2001.

In October 2007, the first IDNA test TLDs were added to the root zone.
These were the first TLDs with non-alphabetic characters. ICANN approved a
policy for allocating IDNA ccTLDs in October 2009 and the first production
IDNA TLDs were added to the root zone in January 2010.

Deployed software that checks DNS top-level labels for conformance with
past allocation policy is likely to reject domain names allocated after a
policy change.

Syntax of TLD labels - protocol level

All labels of a domain name have the same syntax. The syntax of TLDs is
not specially restricted at the protocol level.

   domain  = *(label ".") label ["."]

   label   = let-dig [ldh-str]

   let-dig = ALPHA / DIGIT

   ldh-str = *( ALPHA / DIGIT / "-" ) let-dig

A label can be up to 63 characters long. A domain name can be up to 255
characters long.

A domain name as a whole shall not match the dotted quad representation of
an IPv4 address.

   IPv4    = 3(digits ".")

   digits  = 1*DIGIT

Syntax of TLD labels - allocation policy

The syntax of allocated TLDs is restricted in order to ensure that no
domain name can match an IPv4 dotted quad, and for compatibility with past
practice and deployed software. The policy is subject to change by ICANN.
This section describes the syntax of domain names permitted by the current
allocation policy.

IDNS encodes Unicode strings within the syntax permitted for domain name
labels. The Unicode string used by applications is known as a U-Label;
its corresponding encoding in the DNS is known as an A-Label. The terms
A-Label and U-Label are used in this document as defined in [RFC5890].
Valid A-Labels always contain non-alphabetic characters.

In order to accommodate the wish to express TLD names in scripts other
than the ASCII subset of Latin, it is necessary to allow non-alphabetic
characters in the corresponding TLD DNS-Labels.  Following past practice,
the U-label form of a TLD name is restricted by applying rules analogous
to those already imposed on ASCII TLD DNS-Labels.

ASCII TLDs have the following syntax:

   TLD = 1*63(ALPHA)

IDNA TLDs obey the following requirements:

   3.  the general category of all code points, is one of { Ll, Lo, Lm, Mn }.

[... etc etc ...]

Tony.

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Nov 2010 13:35:34 -0800

Generally I like this, and it is a much more thorough treatment than 
what I was working on. I think it needs a little wordsmithing, and I'm 
not clear if Tony's intention in the last section is to indicate that 
there should be a protocol restriction on non-IDN labels (which 
obviously I oppose). Otherwise I think this is definitely a step in the 
right direction.

Doug

--

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Nov 2010 13:37:32 -0800

On 11/25/2010 09:52, Andrew Sullivan wrote:
> It seems to me that those who don't like the document

You may recall that my first post on the topic did actually offer a 
diff. My intention was to be minimalistic to avoid changing the text too 
much at this stage, but as I just posted I like the direction Tony is 
going much better.

Doug

--

---

From: Richard Clayton <[email-masked]>
Date: Fri, 26 Nov 2010 21:47:51 +0000

In message <[email-masked]>, Doug Barton
<[email-masked]> writes

>much at this stage, but as I just posted I like the direction Tony is 

as did I ... but I wish he'd carried on, because I'd like to see a
chatty explanation of what the explicit rules meant before suddenly
diving into the excruciating detail of { Ll, Lo, Lm, Mn } etc

ie: I would like to be able to read this RFC and understand in general
terms what it meant without ever bothering to look at 5890 (or it seems,
since that isn't the right place, at several other RFCs as well)

ie: the only people who'd need to follow the references would be those
who were proposing something challenging like .666, .3d or .4men (and
especially the cyrillic equivalents of these) and who wanted to know if
this was likely to lead to tears before bedtime.

- -- 
richard @ highwayman . com                       "Nothing seems the same
                          Still you never see the change from day to day
                                And no-one notices the customs slip away"

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Nov 2010 14:15:38 -0800

On 11/25/2010 06:56, Andrew Sullivan wrote:
> "merely" a policy one.

No, I haven't. I have specifically said, on numerous occasions now, that 
I expect software which does what you yourself described (OBE tests 
about what a TLD is) to break. So sure, let's call that a "technical 
problem."

What I DID say, also on numerous occasions, is that:

1. 1123 does not describe a restriction on the protocol
2. We should not add one
3. The responsibility for dealing with the fallout from the technical 
problem lies within the ICANN policy development process.

> I am arguing that, given that some people

I have also said that I'm leaning towards the idea that a paragraph 
which addresses the issue is in scope here. Where we differ is that I 
think "address" means "supply a warning" where you think it means "Tell 
people they can't do that."

I think part of the disconnect here is related to something that I ran 
into rather often in my time running IANA. "Back in the day" (e.g., 
during the time period when 1123 was written) you had a handful of 
people who all wore a lot of hats. If you got the right 2 or 3 people 
together in a room you could easily make decisions about almost any 
topic, and those decisions would almost always be right. As the network 
grew and roles/responsibilities differentiated into different people 
and/or organizations that process both became more difficult, and more 
"human;" by which I mean that you started having people becoming more 
interested in making sure that their areas of decision making did not 
become smaller *cough*turfwars*cough*. Now enter ICANN, which was 
scientifically designed to step on everyone's toes, and hilarity ensues.

I've been ruminating on what you, and others have said on this topic and 
I think we've hit one of the relevant icebergs here. For example, from 

> you there isn't a problem," then we ought to be ashamed of ourselves.

To me that sounds like you think it's the IETF's job to make sure that 
people are not _allowed_ to do something that might cause them (and 
their registrants) problems. I think this view is rooted in good 
motives, and that you (and others) honestly believe that you're doing 
the right thing here by trying to remove bullets from the foot-shooting 
gun.

However my view is that you're wrong on both counts. The policy 
questions regarding TLDs are in ICANN's court now, and because there is 
no protocol reason that TLD labels cannot contain digits, this IS a 
policy question. That doesn't mean that we shouldn't put a big red 
warning label on 1123-clarify, it just means that it's not in our 
bailiwick to say "no."

> anyway.  It's a straw person.  Moreover, while we're talking about

Um, no. My intent was not to start a debate about labeling logical 
fallacies. My intent was to point out that I do not appreciate your 
attempt to characterize me as a foolish person, and that I do not 
believe that behavior of that nature is appropriate in the IETF. The 
fact that by extension your attempt to make me appear foolish is also an 
attempt to weaken the plausibility of my argument is the fallacy. Feel 
free to label that whatever you want.

> . . . this is just a slippery slope argument, and not a very good one.

Um, yeah, that's sort of my point. :)  Oh wait, you meant me ....

> the feature is worth the potential cost.

Yes, that is also my point. /me getting confused ....

> breaks, people have something they can read in order to understand

Ah, now I get it. You're arguing that the protocol restriction did exist 
in the past, and now we're relaxing it, but only slightly. I'm arguing 
that the protocol restriction never existed, and therefore you are 
attempting to create one. My understanding of the support for your 
argument is that "lots of people already believed that this was so." 
(And to be clear, that's not a snark, if I'm wrong feel free to correct 
me.) My point is that we've already blown way past the historical 
restrictions on TLD labels, not once but twice. Therefore attempting to 
assert that a protocol restriction ever existed is both wrong (arguable, 
but moot because ...) and OBE (not arguable).

> am most concerned about.

Yep, I get it, I have the same concerns, and in fact already lived 
through this exact problem in the early-2000's. Please don't think that 
I do not understand your concern. We are simply reaching different 
conclusions about it.

I (and others) think that the benefits of allowing creativity at the top 
level outweigh the costs of people having to fix old stuff. I thought 
that back in 2000, have always believed it, and will continue to believe 
it because the other side of that coin is that we just don't innovate at 
all "because stuff will break."

Doug

--

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 26 Nov 2010 17:28:39 -0500

On Fri, Nov 26, 2010 at 02:15:38PM -0800, Doug Barton wrote:

> in the past, and now we're relaxing it, but only slightly.

No, I'm arguing, just as the document does, that some people may have
understood this to be a protocol restriction because the document was
not crystal clear about what was policy and what was not.  My personal
view is that it _was_ policy, that it was called out as such, and that
if things break then that's a pity.  But as an IETF geek, I'm
concerned about interoperability.  And so since the protocol/policy
line was not always drawn as brightly in the past as it maybe could
have been, let's explicitly say that certain things are just hunky
dory.

In my opinion, the alternative to this is to say nothing.  If you are
right and there never was any protocol issue here, then ICANN has
taken over that problem and we don't have to solve it. 

A

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 27 Nov 2010 09:39:46 +1100

In message <[email-masked]>, Tony Fi
> A domain name as a whole shall not match the dotted quad representation of

Which doesn't come close to matching all the possible component
forms supported by inet(3) on POSIX machines.

The octet 10 (decimal) can be expressed in all these forms on POSIX
machines.

	 0x0a, 0xa, 012, 10

Additionally 10.6666 *is* a valid IPv4 address so one has to worry
about all values up to 4294967295 expressed in decimal, octal and
hexadecimal as a minimum to precent accidental collisions.

	0 .. 037777777777
	0 .. 0xffffffff
	0 .. 4294967295

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Nov 2010 08:14:52 +0900

Tony Finch wrote:

> It describes the current
> No distinction is made between upper and lower case.

How can you define upper case of 'y' with diaeresis' in Dutch
context where

   http://en.wikipedia.org/wiki/IJ_%28digraph%29
   (lowercase y with diaeresis), ij and Y, IJ are identical.

?

Note that upper case of 'y' with diaeresis' is not 'Y' with
diaeresis but plain 'Y' without diaeresis, because, unlike 'i'
and 'j', 'I' and 'J' do not have a dot in their character
shapes.

> In order to accommodate the wish to express TLD names in scripts
> other than the ASCII subset of Latin, it is necessary to allow
> non-alphabetic characters in the corresponding TLD DNS-Labels.

The example above is using only alphabetic Latin characters.

> Following past practice, the U-label form of a TLD name is
> restricted by applying rules analogous to those already
> imposed on ASCII TLD DNS-Labels.

So, how can you define upper case of 'y' with diaeresis' in
Dutch context?

And, beyond Latin, how can you define similar equivalence,
which is necessary for TLD registration operation, of extended
case insensitivities?

						Masataka Ohta

---

From: Doug Barton <[email-masked]>
Date: Fri, 26 Nov 2010 15:25:17 -0800

> have been, let's explicitly say that certain things are just hunky

Ok, so you're using different words but the end result is the same, and 
I still object.

> In my opinion, the alternative to this is to say nothing.

I actually have a lot of sympathy for this course of action. But given 
what I know about the policy side of it, and the fact that Joe/ICANN is 
the author of the current draft, I seriously doubt that we can beg off 
here.

Doug

--

---

From: Jaap Akkerhuis <[email-masked]>
Date: Sat, 27 Nov 2010 01:08:10 +0100

Your mileage varies.  They are sometimes condidered identical,
sometimes they aren't. The Dutch alphabet has a variable number of
characters depending the (edition of the) dictionary or (telephone)
directory you consult. Some heap them together, some don't at all,
some do some.  It makes playing word games such as creating a
"panzin" (make the shortest sentence using all available characters)(*)
a challenge.  Probably comparable to the problem of establishing
the number of angels which might be dancing on a pin while herds
of camels goes through the pin-hole (or not).

Since there are no language contexts in DNS at all, so the squabbling
about these things is completely irrelevant for this list.

	jaap

(*) http://www.dbnl.org/tekst/bran023oppe01_01/ has quite some info in
    this.

---

From: Masataka Ohta <[email-masked]>
Date: Sat, 27 Nov 2010 09:41:27 +0900

Jaap Akkerhuis wrote:

> sometimes they aren't.

The problem is not identity between "IJ" and 'Y' but identity

> > No distinction is made between upper and lower case.

is the context.

> about these things is completely irrelevant for this list.

Lack of locale at root zone does not make equivalence definition
between TLDs unnecessary.

An international equivalence could be transitive closure of
equivalences of all the possible locales.

						Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Sat, 27 Nov 2010 01:20:37 +0000

On 26 Nov 2010, at 21:35, Doug Barton <[email-masked]> wrote:

> Generally I like this, and it is a much more thorough treatment than what I was working on.

Glad you like it.

> I think it needs a little wordsmithing,

Definitely. It's just a quick hack to get across the protocol/policy distinction and isn't supposed to be at all polished.

> and I'm not clear if Tony's intention in the last section is to indicate that there should be a protocol restriction on non-IDN labels (which obviously I oppose).

No, that part is supposed to describe current allocation policy.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Sat, 27 Nov 2010 01:31:03 +0000

> forms supported by inet(3) on POSIX machines.

Yes indeed. Is there a formal spec in any RFC we can refer to? RFC 1123's #.#.#.# doesn't cut it. RFC 3986 is very strict about the form of IP addresses in URLs. I tend to think that is closer to the right approach in this context than allowing the full insanity of inet_aton.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Sat, 27 Nov 2010 10:57:27 -0500

> a description of the TLD allocation policy at that time.

What's your basis for this assertion?

We (authors of draft-liman-tld-names) I think are pretty comfortable asserting that some implementors may have understood the phrase [...] to be a protocol restriction. That seems fairly easy to support, and perhaps the text in 1123 itself is a sufficient existence proof.

I don't know how to defend an assertion in absolute terms that this understanding is categorically wrong. How would you do it?

Joe

---

From: Tony Finch <[email-masked]>
Date: Sat, 27 Nov 2010 18:02:23 +0000

> I don't know how to defend an assertion in absolute terms that this understanding is categorically wrong. How would you do it?

As I have said before, RFC 1123 is very clear that DISCUSSION sections are for clarification and explanation. They do not impose requirements that do not exist in the normative sections.

 Under many of the individual topics in this document,
 there is parenthetical material labeled "DISCUSSION"
 or "IMPLEMENTATION".  This material is intended to give
 clarification and explanation of the preceding requirements
 text.  It also includes some suggestions on possible future
 directions or developments.

Tony.

---

From: Joe Abley <[email-masked]>
Date: Sat, 27 Nov 2010 13:25:21 -0500

> As I have said before, RFC 1123 is very clear that DISCUSSION sections are for clarification and explanation. They do not impose requirements that do not exist in the normative sections.

That argument speaks to the question of whether 1123 imposes a requirement, but not whether the requirement discussed in 1123 existed. The fact that it was discussed, in a DISCUSSION section as you point out, surely suggests that it did exist, and absent any subsequent clarification, presumably still does.

We're talking about an era where documentation was often not especially rigourous, and when the state of the network frequently depended on information that existed only in peoples' heads, or pragmatically in software produced by early implementors. Maybe a reference to the restriction is as much as we can hope for from 1123.

I still don't feel that the assertion that no requirement existed is defensible.

Joe

---

From: Suzanne Woolf <[email-masked]>
Date: Sat, 27 Nov 2010 18:50:10 +0000

On Sat, Nov 27, 2010 at 01:25:21PM -0500, Joe Abley wrote:
> We're talking about an era where documentation was often not
> especially rigourous, and when the state of the network frequently
> depended on information that existed only in peoples' heads, or
> pragmatically in software produced by early implementors. Maybe a
> reference to the restriction is as much as we can hope for from
> 1123.

I think the fact that this discussion has gone on so long and
encumbered so many electrons supports the contention underlying the
draft that there is an ambiguity, based exactly as Joe suggests here.

The draft carefully doesn't rely on any assertion of a prior
restriction as the basis for clarifying the spec as we want it to be
today. It does assert the ambiguity that I think we're busily
demonstrating in this discussion.

Old specs are full of such ambiguities, which are mostly harmless
because they don't harm interoperability or the potential harms have
been addressed by implementors in practice. In this particular case,
hwoever, the "interoperability" boundary could reasonably be argued to
be between protocol and policy as much as between implementations.

Rather than explaining to either future implementors or people whose
primary orientation is policy that "we couldn't agree there was any
ambiguity here that we needed to address," or "some protocol standards
are more equal than others," let's make this unambiguously normative.

Suzanne

---

From: Tony Finch <[email-masked]>
Date: Sat, 27 Nov 2010 22:37:29 +0000

> That argument speaks to the question of whether 1123 imposes a requirement, but not whether the requirement discussed in 1123 existed. The fact that it was discussed, in a DISCUSSION section as you…

The alphabetic requirement was part of the allocation policy, not as part of the syntax. The syntax is explained perfectly precisely in the normative text and it very clearly makes no restriction on the syntax of TLDs.

Why is it so hard to keep the policy separate from the underlying syntax?

Tony.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Sat, 27 Nov 2010 19:38:07 -0500

On 11/27/10 1:25 PM, Joe Abley wrote:
...
> That argument speaks to the question of whether 1123 imposes a requirement, but not whether the requirement discussed in 1123 existed. The fact that it was discussed, in a DISCUSSION section as you…

921 contained an alpha-only restriction on the first character in 
simple names, repeated for hierarchical names.

as the protocol did not exist when jon wrote 921 (1984), and would not 
exist for another three years, when paul wrote 1034/35, let alone five 
years later when bob edited 1122/23, which i and many others worked 
on, and no doubt introduced errors, the "restriction" is protocol 
independent.

> We're talking about an era where documentation was often not especially rigourous, and when the state of the network frequently depended on information that existed only in peoples' heads, or pragm…

agree on the lack of rigor in documentation. disagree on the lack of 
rigor in test case specification (which is what a bake-off is), though 
the test cases themselves frequently were not committed to archival 
documentation.

software architecture comes in many forms, and formal specification is 
only one of them.

your claim reduces to a "2b" test case, which when fed to some dns 
iut, caused other than expected results, if present as the anchor 
proximal label, but not if present as any other label. does anyone 
actually have an equivalent test case in their regression suite?

> I still don't feel that the assertion that no requirement existed is defensible.

if you could point to an implementation, circa 1983, for which an 
interoperable standard was subsequently created in 921, or circa 1987, 
when paul wrote his implementation and documented it as 1034/35, for 
which an assumed protocol restriction can be supported by software 
forensics, or later, when bob edited 1122/23, that would tend to 
support your position.

assuming you can do any one of these three things, how large the 
installed base of that particular assumed protocol restriction is the 
next question to ask.

-e

---

From: Tony Finch <[email-masked]>
Date: Sun, 28 Nov 2010 21:41:44 +0000

> draft that there is an ambiguity, based exactly as Joe suggests here.

I agree that the point needs clarifying. I disagree with the form of the proposed clarification. It unnecessarily muddles the protocol and policy layers.

The question of which TLDs are allocated and what restrictions are necessary for the stability of the DNS is a policy matter under ICANN's responsibility.

Tony.

---

From: James Mitchell <[email-masked]>
Date: Mon, 29 Nov 2010 10:17:39 +1100

It looks like we all agree to disagree.

I agree on having a draft that spells out the facts, and as Tony said, leave the decision of allocation policy to ICANN? My thoughts on what such a draft may look like are below..

=======

1. Requirements on composition of TLDs
no requirements over and above normal host names
i.e. can be 1*63 [a-z] [0-9]  and hyphen, cannot start or end with hypen etc..
[I think we can all agree that the internet will not break if ".8-ball" was added to the root, as to whether it works...]

For IDNs, must be valid a-label and u-label 

2. Potential Issues
The internet will not break with allocation of new TLDs, however the following considerations should be noted.

2.1 RFC1123
application developers may have made assumptions about composition of domain names; applications may not recognise new TLD. this has been seen with .museum..

2.2 Confusion with IP Addresses
TLDs that begin with a digit may be confused with IP addresses
TLDs that begin with 0x may be confused with IP addresses
TLDs that are 0-255 may be confused with IP addresses and thus never looked up in DNS as suggested in RFCxxx
[perhaps some of these points become restrictions on the composition of TLDs]

2.3 BIDI domain names
Left-to-right domain names that do not start with a character having BIDI property L will contradict the IDNA BIDI protocol when it is applied. The BIDI protocol should be applied on lookup when the domain name contains a character with [R, AL, AN] BIDI properties...
Additionally RTL labels ending with a digit, that are immediately before LTR labels beginning with a digit, will cause name to be re-ordered and displayed incorrectly.

2.4 Reserved labels
Labels containing hyphens in third and fourth positions should be reserved for future use in protocols as with IDNs. Allocation of such names may cause future stability issues..

3. Validation of TLDs
Application developers should not make assumptions about the composition of TLDs, or the frequency in which they are allocated. if validation is required then looking up the entry in the DNS is a foolproof way to know if a TLD has been allocated. Consideration should be made to reduce queries to the root. Static lists should be avoided.

=======

With the above we will have equipped ICANN and others about what issues can be expected with new TLDs. ICANN can now, with respect to the BIDI issue for example, choose to disallow TLDs beginning with a digit, or have an agreement with the registry operator that RTL or RTL<digit> names are not allowed below the TLD.

James

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Tony
> Finch
> Sent: Monday, 29 November 2010 8:42 AM
> To: Suzanne Woolf
> Cc: [email-masked]
> I agree that the point needs clarifying. I disagree with the form of the
> proposed clarification. It unnecessarily muddles the protocol and policy
> layers.
> 
> The question of which TLDs are allocated and what restrictions are necessary
> for the stability of the DNS is a policy matter under ICANN's responsibility.
> 
> Tony.
> --

---

From: Chris Wright <[email-masked]>
Date: Mon, 29 Nov 2010 23:48:15 +1100

+1

Chris

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Nov 2010 13:50:43 +0000

On Mon, 29 Nov 2010, James Mitchell wrote:
>
> I agree on having a draft that spells out the facts, and as Tony said,
> leave the decision of allocation policy to ICANN? My thoughts on what
> such a draft may look like are below..

Your sketch looks fine to me.

Tony.

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Nov 2010 09:39:20 -0500

> [I think we can all agree that the internet will not break if ".8-ball" was added to the root, as to whether it works...]

It seems to me we can all agree that the Internet will not break if
you register a domain name o'reilly.com, either.  But you're not
allowed to, not because of the DNS rules but because of the hostname
rules and a suggestion in the DNS specification that things will go
better if you follow the hostname rules too.  Why not relax that
restriction?  Why should we be beholden to old-timey restrictions?

> For IDNs, must be valid a-label and u-label 

Why?  That seems like it's "just" a policy preference.  Why should the
IETF have anything to say about it?  Why shouldn't the top level
labels also conform to JFC Morfin's Intersem plans, using multiple
[a-z][a-z]-- prefixes?  What basis do we have for telling ICANN what
valid DNS labels they're allowed to pick?
 
> [perhaps some of these points become restrictions on the composition of TLDs]

Or perhaps, in the interests of making changes near or at the root
incrementally, we adopt the restrictive proposal in the draft and then
write a subsequent one, informed perhaps by more study, that opens the
door wider.
 
> Application developers should not make assumptions about the composition of TLDs, or the frequency in which they are allocated. if validation is required then looking up the entry in the DNS is a f…

Note that we already have an RFC that says roughly what (3) says, and
so we don't need to say it again.

A

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

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 29 Nov 2010 10:03:22 -0500

On 11/29/10 9:39 AM, Andrew Sullivan wrote:

> ... the Internet will not break if
> you register a domain name o'reilly.com,

please either stick to the ldh set and the issue of the validity of 
any string composed from this generating set, or explain why, other 
than for rhetorical excess, you are permitted to pick an arbitrary 
point in the us-ascii standard and wave it about as proof of some claim.

there exist rules, much earlier than 1123, about "-" as the initial, 
or terminal, byte in a sequence of bytes, and about sequences of two 
or more instances of "-" where neither byte is the initial, or 
terminal, byte in a sequence of bytes.

there exist rules, much earlier than 1123, about any digit as the 
initial byte in a sequence of bytes.

there exist rules, much earlier than 1123, about whether a sequence of 
bytes must contain more than one byte.

it is my understanding that a view associated with liman's draft is 
that some protocol restriction existed in fact, or should be 
generously imputed to have existed as a protocol restriction in the 
minds of some implementers, and that one or more of these rules are 
not completely explained as allocation policies by historic allocators 
of some zone of interest.

i don't share that view, and i don't think it prudent to abandon 
whatever merits may support that view by appealing to the absence of 
us-ascii values outside the ldh set, or phrasing like "old timey".

-e

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 29 Nov 2010 10:27:02 -0500

On Mon, Nov 29, 2010 at 10:03:22AM -0500, Eric Brunner-Williams wrote:

> there exist rules, much earlier than 1123, about "-" as the initial, or 

Yes.  They're the hostname rules.  RFC 1035 has this to say about
them, in section 2.3.1:

  The DNS specifications attempt to be as general as possible in the
  rules for constructing domain names.  The idea is that the name of
  any existing object can be expressed as a domain name with minimal
  changes.

  However, when assigning a domain name for an object, the prudent
  user will select a name which satisfies both the rules of the domain
  system and any existing rules for the object, whether these rules
  are published or implied by existing programs.

  For example, when naming a mail domain, the user should satisfy both
  the rules of this memo and those in RFC-822.  When creating a new
  host name, the old rules for HOSTS.TXT should be followed.  This
  avoids problems when old software is converted to use domain names.

  The following syntax will result in fewer problems with many

  applications that use domain names (e.g., mail, TELNET).

[. . . ]

  The labels must follow the rules for ARPANET host names.  They must
  start with a letter, end with a letter or digit, and have as
  interior characters only letters, digits, and hyphen.  There are
  also some restrictions on the length.  Labels must be 63 characters
  or less.

Now, we have considerable discussion in the first part of that passage
that explains why the restrictions that are being introduced are so
introduced, despite the fact that the protocol itself happens not to
have such restrictions.  So, are those rules "merely" allocation
policy, or not?  I can't tell, and I say you can't either.  We don't
even have the proto-2119 lanuage here that we see in RFC 1123, so we
can't tell whether the "The labels must follow" in the last paragraph
is a protocol restriction or a consequence of following the "prudent
user" advice that immediately preceeds it.  It might be policy, and it
might not be.

One way to figure out whether this is "mere" policy or whether it is
in fact protocol is to ask people.  It turns out, however, that
different people have responded differently to this.  Some people have
responded by putting eight-bit labels in the public DNS.  

I claim, therefore, that regardless of whether the rule in RFC 1123 is
or is not clearly policy, we should document that we explicitly
permit, as a matter of protocol, certain characters in the top level.
The draft as written carefully points out that there are lots of
things that are policy and not the domain of the IETF.  This just
states that, in case anyone thinks there is a problem with top level
IDNA2008 labels, there isn't.

And I say again (for the last time, since I think I'm just repeating
myself now), if one thinks that the restriction in 1123 is clearly not
a protocol restriction, then there is nothing to say and we can be
quiet.

A

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

---

From: Andreas Gustafsson <[email-masked]>
Date: Mon, 29 Nov 2010 18:01:03 +0200

> responded by putting eight-bit labels in the public DNS.

RFC 2181 section 11 is quite clear that the DNS protocol places no
restrictions on the contents of a label other than its length, and
that eight-bit labels are specifically allowed:

   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. 

-- 
Andreas Gustafsson, [email-masked]

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Nov 2010 16:10:38 +0000

On Mon, 29 Nov 2010, Eric Brunner-Williams wrote:
> terminal, byte in a sequence of bytes, and about sequences of two or more
> instances of "-" where neither byte is the initial, or terminal, byte in a
> sequence of bytes.

There has never been a restriction on consecutive hyphens, otherwise they
would not have been usable in IDN A-labels.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Nov 2010 16:18:58 +0000

On Mon, 29 Nov 2010, Andrew Sullivan wrote:
> policy, or not?

The host name rules are not allocation policy. They are encoded in a
number of protocols, such as SMTP, URI syntax, etc. etc. The host name
rules are a protocol layer above the raw DNS and shared by most
application protocols.

Note there are protocols that put non-hostname labels in the DNS, such as
SRV and DKIM.

Tony.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 29 Nov 2010 12:07:29 -0500

> would not have been usable in IDN A-labels.

"have only letters or digits or hyphen as interior characters."
from 921

now had there actually been a protocol restriction on sequences of 
hyphen longer than one, (years before any implementation of the 
protocol) then your observation would be correct, and we'd have to use 
some other mechanism to signal "interpret as" to some layer above.

-e

---

From: Tony Finch <[email-masked]>
Date: Mon, 29 Nov 2010 17:59:54 +0000

> "have only letters or digits or hyphen as interior characters."

That's an informal description of the formal syntax defined in RFCs 608,
810, 952.

> now had there actually been a protocol restriction on sequences of hyphen
> longer than one, (years before any implementation of the protocol) then your
> observation would be correct, and we'd have to use some other mechanism to
> signal "interpret as" to some layer above.

I am confused. You say double hyphens were forbidden then you say they
were permitted.

I think your earlier message meant that before RFC 1123 the allocation
policy did not exactly match the permitted syntax, e.g. double hyphens and
single character labels were permitted by the syntax but not allocated;
initial digits were not permitted by the syntax but were allocated (and
eventually the documented syntax caught up with the policy).

I also think you are agreeing with my argument that alpha-only TLDs are a
policy matter.

Tony.

---

From: Eric Brunner-Williams <[email-masked]>
Date: Mon, 29 Nov 2010 13:41:46 -0500

> That's an informal description of the formal syntax defined in RFCs 608,

hierarchical names appear in 921, not 608 or 810, and 952 references 921.

> I am confused. You say double hyphens were forbidden then you say they

it would be wicked difficult to change something from forbidden to 
permitted if the underlying rational for the restriction were in 
fielded implementations which were interoperable over some ranges of 
test values.

on the other hand, anything forbidden by policy alone may be 
permitted, and permitted in a non-fictive sense, by a mere change of 
policy.

a restriction which may be relaxed is proof of (a) overspecification 
error in a mechanism specification, or (b) absence of specification in 
a mechanism specification, usually known as a policy statement.

a restriction which must be further restricted is proof of (a) 
underspecification error in a mechanism specification, or (b) a 
restriction of policy.

we seem to be discussing the first case, not the second, when 
discussing texts prior to liman's. we seem to be discussing the second 
case, not the first, and with no claim of underspecification of 
restriction of policy, when discussing liman's text.

> I also think you are agreeing with my argument that alpha-only TLDs are a

i thought that was obvious, but yes, and more broadly, that 
over-constraint is a distraction at best, and potentially worse than a 
mere distraction. no one should have any illusions about the scope of 
error possible, as there are two roots right now, and managing the 
requirements for their increased divergence seems prudent.

and my preference is for no i-d at all at this point. i don't want to 
be in cartagena next week or san francisco next spring or ... and hear 
someone say "the ietf made us do it" for some unfortunate value of "it".

-e

---

From: David Conrad <[email-masked]>
Date: Mon, 29 Nov 2010 11:11:05 -0800

On Nov 29, 2010, at 10:41 AM, Eric Brunner-Williams wrote:
> as there are two roots right now,

Huh?

> and my preference is for no i-d at all at this point. i don't want to be in cartagena next week or san francisco next spring or ... and hear someone say "the ietf made us do it" for some unfortunate value of "it".

Err, no. The IETF already did it. What is already happening is that people accuse ICANN of violating the DNS specifications and/or are refusing to update their hostname parsing software. Having personally been in discussion in which 1123's statement 

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

was taken to mean that the highest-level component label was required to be alphabetic despite the existence of IDNs in the root would suggest to me that a clarifying RFC that says you can have numbers and hyphens in TLDs would be helpful.  I believe the current draft is sufficiently sensitive to the policy vs. protocol distinction to make its publication warranted.

I would be willing to participate in drafting a follow-on RFC that expands on this draft, but I believe it would be useful to stop the bleeding first.

Regards,
-drc

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 30 Nov 2010 21:19:42 +0900

Tony Finch wrote:

> The question of which TLDs are allocated and what restrictions
> are necessary for the stability of the DNS is a policy matter
> under ICANN's responsibility.

As the restrictions affect implementations, it is a protocol,
not policy, matter, just as RFC822 defines allowable e-mail
format which imposes a lot more restriction than that allowed
by SMTP of RFC821.

Or, we must modify implementations every time ICANN changes
its policy.

						Masataka Ohta

---

From: Tony Finch <[email-masked]>
Date: Tue, 30 Nov 2010 13:09:08 +0000

> format which imposes a lot more restriction than that allowed

Spec bugs are not protocol/policy differences.

Just because policy can be implemented in code doesn't mean it is
protocol.

Tony.