Re: Re: Is space allowed in a hostname?

--On Tuesday, 09 July, 2002 15:46 +0200 Dan Oscarsson
<[email protected]> wrote:

> While it could be OK for IDNA to use this definition of
> domain names and matching of them, I is bad if makes it
> impossible to use a standard based on NFC and rules
> allowing for example German s sharp to not match ss, in
> a new class or other technique to get UCS into DNS.

Dan,

It seems to me that there are two separate issues here, which
ought to be separated.   Let's suppose we go down the "new
class" path, more or less as outlined in my draft (just because
it is the only I-D in the pile, not because it is either
complete or correct).  Other examples could fit equally well,
but would be harder for me to explain.

Issue #1 is whether we can have internationalization in that
Class and not use IDNA (or, given Eric's distinction, not using
IDNA-with-nameprep).  The answer had better be "yes", or we are
in serious trouble.   I have made repeated suggestions that IDNA
be explicitly narrowed so that it does not apply to Classes (and
maybe RR labels) that have not been invented yet.  That change
is intended to make sure we don't run into "I already have a
conforming legacy use that your changing away from IDNA will
destroy" complaints or other problems with defining such a Class
in an appropriate way.   I think that fix is easy, beneficial,
and, with regard to anything now being contemplated, harmless
and that we should just make it.

Issue #2 is whether such a new Class specification would be
stuck with the current definition of stringprep, even if it
didn't use IDNA (or IDNA-with-nameprep).  While I would hope
that the answer would be that stringprep would be usable, it is
ultimately just a reference list of tables and transformations.
That implies that a new protocol specification could, if needed,
reference a different (not-in-stringprep) table if that were
sufficiently important, or we could harmlessly add more tables
to a stringprep-bis without impacting nameprep at all.

So, while I am worried about the first issue --i.e., making sure
we don't overconstrain ourselves for no good reason-- I don't
see the second as being a big issue right now.  When there are
proposals to do other things, let's see what they need and act
accordingly.

And, if NFKC doesn't seem to be appropriate for those
hypothetical future approaches, then I would encourage you, and
anyone else who is interested, to try to convince the Unicode
Consortium of that observation and to try to get them started on
a different normalization table with different rules and
different applicability.  I don't think it is likely that the
IETF will be convinced to base a protocol on a table no one has
produced, nor that it will be willing to start producing its own
tables of this sort, but, if there were a different choice that
were well-defined, I think you could get people to look at it.

     john