Subject: [idn] Which names are valid? (was How should labels be encoded?)

From: David Hopwood <[email-masked]>
Date: Wed, 01 Aug 2001 14:03:21 +0100

-----BEGIN PGP SIGNED MESSAGE-----

[I'll discuss the relevance of email address internationalization
to this working group in another reply.]

"Adam M. Costello" wrote:
> David Hopwood wrote:
> > This does make clear, however, that it is not correct for a general
> > purpose resolver interface to reject non-LDH ASCII characters;
> > instead, it should pass through such characters (if no non-LDH
> > characters are used in that domain, the query will simply fail).
> 
> You seem to be confusing queries and responses, or domain names and
> resource records.  Currently, all domain names (which are the things
> that appear in queries) are advised to use the preferred name syntax
> (LDH characters in labels).  The resource records (the things that
> appear in responses, like SOA and SRV data) already contain non-LDH
> characters, and of course they are not rejected for that.

I think you're missing the point, possibly from not having read RFC 2782.
In a query for SRV records, a non-LDH character ('_') is used in the
query string (QNAME), not just the response. The same may apply to a
query with QTYPE=MAILB (RFC 1035 section 8), and possibly others
(although I don't think MAILB is commonly used?)

More generally, nothing in RFCs 1034, 1035 or 2181 prohibited use of
non-LDH names in queries or in registered names; that was simply a
strong recommendation. So, prohibiting them now (as the current IDNA
draft does [*], for example) would be a backward-incompatible change.

[*] From section 3 of draft-ietf-idn-idna-03.txt:

    # If names that are not legal in [NAMEPREP] are passed to an
    # application, it will result in an error being passed to the
    # application with no error being reported to the name server.
    # Further, no application will ever ask for a name that is not
    # legal in [NAMEPREP] because requests always go through [NAMEPREP]
    # before getting to the DNS.

    Since the names used in SRV queries would result in an error from
    nameprep, it's clear that either the protocol labels in a SRV query
    (and other similar cases) must not go through nameprep, or nameprep
    must be changed so that it does not prohibit non-LDH ASCII
    characters, or both.

> Some resource
> records contain domain names (like CNAME and PTR) but some contain
> other things.  The mailbox field of the SOA record, even though it is
> formatted as a sequence of labels, is not a domain name and is not
> expected to conform to the preferred name syntax (although after you
> chop off the first label, the result is a domain name and is expected to
> conform).  I gather than the same is true of the SRV record.

What do you propose to call the query string used for a SRV lookup
(e.g. "_ldap._tcp.example.com"), if not a domain name? It is certainly
a domain name as defined and used in RFCs 1034, 1035 and 2181 (although
not a host name).

However, as I said, this does not cause any problem provided that
resolver interfaces don't reject non-LDH US-ASCII octets in queries.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 1 Aug 2001 22:02:36 +0000

David Hopwood <[email-masked]> wrote:

> query string (QNAME), not just the response.

I stand corrected.  I was not aware that non-LDH characters were welcome
in DNS queries.

This raises the question:  Is _ldap._tcp.example.com a domain?  Or is it
a creature like the mailbox field of SOA records, a sequence of labels
that does not name a domain?

Could the name server for example.com contain SOA and NS records for
_tcp.example.com, and the name server for the latter contain the SRV
record for _ldap._tcp.example.com?  If we want the answer to be yes,
then _ldap._tcp.example.com must really be a domain.  If the answer is
no, we could say it's not a domain, just a sequence of labels, of which
all but the first two form a domain name, and IDNA would apply only to
those labels.

Perhaps nameprep is not the right layer for the non-LDH ASCII
prohibition.  Maybe that belongs at a higher layer, the same layer that
checks for beginning/ending hyphens.  In other words, put all the checks
related to preferred name syntax in one place, where they can be skipped
if they don't apply.

By the way, I already had plans to make a slight change to AMC-ACE-Z
so that all ASCII characters are encoded literally, not just LDH
characters, because it makes the encoder slightly simpler, and has no
effect for names that avoid non-LDH ASCII characters.

AMC

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 01 Aug 2001 18:13:45 -0500

> Hostnames have naming prohibitions due to the legacy of RFCs 972/1123

should be 952/1123

one of my common typos

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Eric A. Hall" <[email-masked]>
Date: Wed, 01 Aug 2001 18:08:40 -0500

> This raises the question:  Is _ldap._tcp.example.com a domain?

It is a domain name associated with one or more resource records.

> Or is it a creature like the mailbox field of SOA records, a sequence
> of labels that does not name a domain?

Email addresses are stored as data in a resource record. They use the
domain name syntax so they can be compressed in the DNS message, but do
not otherwise fall under the purview of any domain name rules (an email
address can exist as DNS data, be a completely invalid domain name, and
still exist -- just not as a piece of data that is probably useful).

> prohibition.  Maybe that belongs at a higher layer, the same layer
> that checks for beginning/ending hyphens.

That is the application layer.

Hostnames have naming prohibitions due to the legacy of RFCs 972/1123 (the
old HOSTS.TXT database naming spec). Domain names in particular do not
have these prohibitions, but instead, applications apply (or ignore) the
hostname prohibitions when they have to use the hostname for a lookup
operation. EG, since the hostname could exist in /etc/hosts or in DNS, the
"hostname rules" apply regardless of where the data is stored or the
mechanism used to retrieve it.

Applications will continue to have these rules until they choose to extend
their specific ruleset.

---

From: [email-masked]
Date: Thu, 02 Aug 2001 09:38:17 +1000

> I stand corrected.  I was not aware that non-LDH characters were welcome

	The DNS doesn't care about the contents of labels.  It's the
	applications that use the DNS that care.

> This raises the question:  Is _ldap._tcp.example.com a domain?

	Yes.  It's not a hostname however.  Underscore was prepended
	to these labels to avoid collisions with hostnames.  This
	allows you to delegate a tcp domain with having problems
	with using SRV records for the parent domain.

	A real life example that used to exist.  CSIRO had a division
	called Tropical Crops and Pastures.  Its domainname was
	tcp.csiro.au.  Without the underscores you would have had
	to put the SRV records for csiro.au in the tcp.csiro.au
	zone.  This was bad.  Paul had trouble convicing Jon of
	this which is why the first SRV RFC didn't have the
	underscores and the second one does.

> Or is it

	The RNAME field is a domainname, however it is not a hostname
	(maildomain) though it contains a hostname (maildomain).

> record for _ldap._tcp.example.com?

	Yes.  People do this all the time to intergate W2K into
	BIND where they don't want example.com to be modified but
	they still want to support the dynamic updates of the DNS
	by W2K AD.

>  If we want the answer to be yes,
> then _ldap._tcp.example.com must really be a domain.

	It is.

> If the answer is

	I tried very, very hard to get the concept of hostname,
	maildomain and domainname across very early in this process.
	You are only now realising that domainname is a supperset
	of hostname and maildomain.

> related to preferred name syntax in one place, where they can be skipped

	That's where these checks are today.  They are in the
	get*by*() routines not in the res_*() though there are
	res_*() subroutines that will tell you if the name is valid
	in a particular context.

	I also don't consider get*by*() to be resolver routines
	even though they are sometimes in libresolv.  get*by*()
	sit above several databases of which the DNS is one.

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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Thu, 09 Aug 2001 13:54:46 +0100

> a domain name as defined and used in RFCs 1034, 1035 and 2181 (although

with respect:
draft-ietf-idn-requirements-08.txt has been in the group for a LONG time.

                Harald

1.3 Definition of "hostname" and "Internationalized Domain Name"

In the DNS protocols, a name is referred to as a sequence of octets.
However, when discussing requirements for internationalized domain
names, what we are looking for are ways to represent characters that
are meaningful for humans.

In this document, this is referred to as a "hostname". While this term
has been used for many different purposes over the years, it is used
here in the sense of sequence of characters (not octets) representing a
domain name conforming to the limited hostname syntax RFC 952.

This document attempts to define the requirements for an
"Internationalized Domain Name" (IDN). This is defined as a sequence of
characters that can be used in the context of functions where a hostname
is used today, but contains one or more characters that are outside the
set of characters specified as legal characters for host names
RFC 1123.

---

From: David Hopwood <[email-masked]>
Date: Fri, 10 Aug 2001 19:35:53 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> draft-ietf-idn-requirements-08.txt has been in the group for a LONG time.

The definitions in that draft are not entirely satisfactory. For example,
consider "_ldap._tcp.π.com". This is clearly a domain name, and it is
clearly internationalized, so the most sensible thing to call it would be
an internationalized domain name. However, it is not a hostname (although
"π.com" is). It makes no sense to lose the useful distinction between
hostnames and domain names just because they are internationalized.

Note that the remit of this WG is to develop standards for internationalized
domain names, not just internationalized hostnames. Users will not be very
happy if lookups for SRV records below a non-ASCII domain don't work.

- --

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 13 Aug 2001 16:16:39 +0200 (CEST)

> consider "_ldap._tcp.Ï€.com". This is clearly a domain name, and it is
> "Ï€.com" is). It makes no sense to lose the useful distinction between

So is "_ldap._tcp.Ï€.com"" a domain name with a hostname component??
[my mail UA seems to have problems with the characters above - it might not
look the way you sent it.]

The reason we can't just drop the distinction between host names and domain
names is that many application protocols handle host names under the
restrictive specification of valid host names. When looking at transition
issues the impact on those application protocols is key.

So should we say something specific (e.g. as part of the scope
in the requirements document) about domain names with
host name components or substrings?

   Erik

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 13 Aug 2001 10:51:47 -0500

> host name components or substrings?

I think that this question needs to be answered by management.

It would be nice to drop the hostname rules, but at the same time, there
are many many techno-political issues in doing so. The security issues are
just convoluted, for example, as are the intellectual property issues
faced by ICANN and the registrars/registries.

One quick example: RFC1035 allows a period in the middle of a label by
escaping it, and the only reason we don't have www/.aol.com issues now is
because the hostname rules prevent www/.aol from being registered as a
domain. Many similar shenanigans will be possible with IDN.

This kind of situation can go away, but I don't think its in the IDN WG
scope to make that call. We should only be worrying about the technology
issues, and leave policy to the policy makers.

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Tue, 14 Aug 2001 09:16:47 +0200

--On 10. august 2001 19:35 +0100 David Hopwood <[email-masked]> 
wrote:

> consider "_ldap._tcp.Ï?.com". This is clearly a domain name, and it is
> "Ï?.com" is). It makes no sense to lose the useful distinction between

the draft was written after we had already established the IDN WG's name.
It would be logical to call Ï.com an Internationalized Host Name, and 
_ldap._tcp.Ï.com an Internationalized Domain Name, but at the time, 
changing the definition of an IDN that most people in the group had in 
their minds didn't seem worth it.

This may have been a mistake.

                Harald