[idn] Re: Is space allowed in a hostname?

[John C Klensin <klensin@jck.com>]

(I've added the IESG back into this note, as I think we finally
have a problem statement worth bothering them with)

--On Tuesday, 09 July, 2002 17:04 +0200 Simon Josefsson
<jas@extundo.com> wrote:

> John C Klensin <klensin@jck.com> writes:
> 
> [snip]
>> NFKC is, IMO, guilty of one severe sin, and it is the one I
>> believe Simon was pointing out (but it isn't a new observation
>> either): it is not consistent when examined on a language by
>> language and code-point by code-point basis.  If a single
>> meta-rule could be made up that would identify the "right"
>> choice for IETF and DNS purposes, it would handle some sets of
>> characters consistently with the rule and some inconsistently.
>> But, again, no better solution is on the table, and, in all
>> likelihood, no objectively better solution is possible: no
>> single, simple, statement can be made that accurately predicts
>> whether characters are duplicated or unified in the
>> Unicode/10646 code set itself.  The allocation decisions may
>> well have been made rationally, but enough different rules
>> were applied, and generic enough rules were applied, that it
>> would be unreasonable to expect complete consistency with
>> any simple rule, much less an IETF-optimized one.
>> 
>> It is all going to come down to arbitrary choices at some
>> stage. Some of those arbitrary choices are going to irritate
>> some groups of people and seem harmless to others.  If they
>> were made a different way, different people would be
>> irritated.
> [snip]
> 
> This was a good summary.
> 
> I think the reason that I and others are bringing up old
> questions is that several of us did participate when this
> working group started, raising these questions.  We are now
> expecting that the documents answer the questions, or where
> they cannot be answered to everyone's agreement, at least say
> what inherent problems and risks are caused by not solving the
> problems completely.  Since internationalized strings is a
> tricky subject, it is IMHO as important to carefully describe
> what problems are _not_ solved as to describe what problems
> actually are solved.  Admittedly, the latest document revision
> fixed several of my pet problems (thanks!), but being new to
> the topic and not having read the specifications all that
> carefully makes me worry about there being other inherent
> problems that aren't documented or discussed.

We are in violent agreement.

My understanding, when we gave up on the "Requirements" document
(for what I still believe were good reasons), was that it would
be replaced by an exact statement of the problem the WG thought
it was solving and, ideally, a review of problems that seemed to
fall within the IDN space that it was not trying to solve.
Implicit in that was the assumption that the WG's outputs would
be narrowed and focused to that statement and tested, where
appropriate, against it.

Instead, we are missing that statement and, without it, seem to
have a collection of specifications that are underspecified in
some areas and that overreach in others.  Given that, as you
say, internationalized strings are a tricky subject, that isn't
a good situation.  

And it leads me to conclude that, even if I believed that IDNA,
as now defined from a protocol standpoint, were a perfect match
for the critical problem being solved, it would still be vitally
important to carefully describe that problem and then to trim,
narrow, and focus the relevant documents.

      john