Subject: [dnsext] RE: On adoption of two drafts ...

From: Alfred Hönes <[email-masked]>
Date: Wed, 19 May 2010 16:33:26 +0200 (MESZ)

Vaggelis Segredakis wrote:

> In the .gr ccTLD we have presented in 2005 the option of registering
> IDN domain names in Greek.  The Greek language requires for all
> multi syllabus words to have an accent sign called "tonos" over
> one of the letters.  [...]

Unfortunately, hereby we apparently are back at one of the greatest
ratholes ever seen in DNS internationalization.

Wasn't it one of the fundamental characteristics of the DNS that
DNS labels are _not_ "words" (in any language), but simply abstract
_identifiers_ in a more user friendly alphabet than IP addresses?

I vaguely recall from IDNA discussion on the use of IDNA with the
Arabic languages (and scripts) that it had been reported to the
IETF community that "The hardest part in this work was to escape
from the (mis)concept of a couple of stakeholders that DNS labels
were 'words' in one of the Arabic languages and therefore linguistic
rules would have to be superimposed on DNS labels."

If application of a linguistic rule for Greek is the sole background
of your requirement, aren't we in a similar position again?

I do not support work on DNS protocol changes based on such
specific (and arguably inappropriate) reasoning.  If we shall
undertake such effort, a "neutral" problem statement needs to be
formulated and taken as the _only_ base for the subsequent work.

IMO, for any purpose to be discussed here, the definition of DNS
labels from the basic DNS standards should be taken for given,
and this WG should refrain from imposing semantic rules of any kind
on DNS labels.  In other words: DNS Protocol mechanisms should work
with any semantics imposed in a uniform manner by other bodies on
*all* DNS labels.  Scoped semantics of specific classes of DNS labels
MUST remain out of scope of the discussion in this WG.

If we agree on a generally desirable scheme/model of "equivalence"
of domain _names_ (any restriction to equivalence of single _labels_
within a zone IMO is not worth such effort), it may happen that
someone can apply the ensuing protocol extensions for purposes not
amenable to consensus in the IETF; they may deploy such usage,
but that MUST NOT become topic of discussion in this WG, if we
actually want to arrive at success *within any finite time span*.

A few general thoughts:

The examples shown so far seem to indicate that any generally
useful equivalence scheme needs to admit composition and iteration.
I.e., it must be possible to store an equivalence for a single label
that somehow automagically applies to all compositions containing
the domain name which an instance of the equivalence mechanism is
regarded to have as its owner, and such equivalences can happen
to be 'crossed' multiple times in the resolution process of a multi-
label DNS name.

The variety, complexity, and context-specifity of equivalence 'nets'
envisioned makes it clear that neither end system resolvers nor
caches should be burdened with extraneous storing and/or processing
requirements for equivalences.  Equivalences mentioned so far
apparently are neither generic nor symmetrical.
This IMO implies that these 'equivalences' are not equivalence
relations in a mathematical (set theoretical) sense; each instance
of an 'equivalence class' instead needs to be represented by a
simply-connected, loop-free, directed graph with a 'canonical' name
form (chosen by the entity defining the instance of equivalence)
at its (inverted) root.
Each byte of information on any instance of equivalence must be located
in the respective authoritative zones, and the nodes and arcs of that
graph must be represented "in the DNS way", to allow transporting the
information from the authorities to the resolvers in the standard way
that admits "vouching" for these components of the graph by normal
DNSSEC.  In this model, the nodes in the equivalence graphs are
represented by DNS nodes, and a directed arc ("arrow") in an
equivalence graph is represented by an RR at the 'source' of the arc,
pointing to the 'target' of the arc.
(This is the model already present in CNAME and DNAME -- set aside
synthetic CNAME generation for DNAME.)

Kind regards,
  Alfred.

-- 

+------------------------+--------------------------------------------+
| TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., Dipl.-Phys.  |
| Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18         |
| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
+------------------------+--------------------------------------------+

---

From: "Vaggelis Segredakis" <[email-masked]>
Date: Wed, 19 May 2010 18:13:41 +0300

Dear Alfred,

Thank you for your email. I would be one of the first to agree with you that
a domain name should not be considered a word, it is a number mnemonic
reference. It is however a fact of modern life that domain names are used as
words, some of them even across several language platforms and character
sets and most words are used for domain names. 

I do not want to present a linguistic problem to the DNSEXT WG for a
solution. As a registry we are looking for a technical solution to DNAME a
domain tree right from the top, not one layer below. Call it DNAME+CNAME,
BNAME, xNAME or any other future technical term. My report of the actual
details of how this need appeared along with IDNs was there as a historic
and explanatory reference to our request.

The discussion *if* this issue really is an issue has already taken place on
February the 16th. From the meeting minutes: "There was enough indication of
support to suggest that the WG might want to tackle the problem". What we
lack now is some clear path of work to identify which proposed solution
would be good to begin with.

Best,

Vaggelis

-----Original Message-----
From: Alfred HΞnes [mailto:[email-masked]] 
Sent: Wednesday, May 19, 2010 5:33 PM
To: [email-masked]
Cc: [email-masked]
Subject: RE: On adoption of two drafts ...

A few general thoughts:

Kind regards,
  Alfred.

--

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 28 May 2010 09:54:38 +0200

On Wed, May 19, 2010 at 04:33:26PM +0200,
 Alfred Hönes <[email-masked]> wrote 
 a message of 92 lines which said:

> Wasn't it one of the fundamental characteristics of the DNS that DNS
> labels are _not_ "words" (in any language), but simply abstract
> _identifiers_

That's what people like John Klensin keep repeating but repetition
does not make it true.

Either DNS labels are semantic-free identifiers (like the phone
numbers), whose sole advantage (but it is a big one) over IP addresses
is the stability. That way, everyone would be equal, whether they
speak english or german or greek or arabic. And everyone would be
unhappy.

Or DNS labels are mnemonics and it is more convenient but it has bad
consequences (TLD registration rules, UDRP, etc) and it means we have
a responsability to be sure that these mnemonics can be written in any
script (hence IDNA).

[I used "mnemonics" instead of "words" to emphasize that, even in
english, you cannot have every name for a DNS label, for instance
"O'Reilly" or "Bang & Olufsen".]

> Arabic languages (and scripts) that it had been reported to the IETF
> community that "The hardest part in this work was to escape from the
> (mis)concept of a couple of stakeholders that DNS labels were
> 'words' in one of the Arabic languages and therefore linguistic

It is not a misconcept.

---

From: [email-masked]
Date: Fri, 28 May 2010 10:53:38 +0000

On Fri, May 28, 2010 at 09:54:38AM +0200, Stephane Bortzmeyer wrote:
>  Alfred Hvnes <[email-masked]> wrote 

	Sorry, but I side w/ John and Alfred. A DNS label is a string
	with (well) defined construction.  Any semantic value is in the
	eye of the beholder and is not intrinsically part of the string.
	Ergo, any memnonic value is tied to how a string is sold/marketed
	and is not intrinsically part of the string.

--bill