Re: [idn] Re: An idn protocol for consideration in making therequirements

[ned.freed@innosoft.com]

> The problem is the 'ph6' prefix. Whatever the prefix, if we follow
> this proposal, before starting any deployment whatsoever, we have
> to nail the prefix down. From there on, domain names with that prefix
> cannot be registered anymore.

Sure they can -- all you have to do is encode them using the scheme presented
in the draft. This is equivalent to saying you cannot have equals signs in
quoted-printable material because equals is the quoting character. Sure, you
cannot have bare equals signs in the encoded output, but you certainly can have
them under the encoding.

One of the things we learned during the discussions that led up to the creation
of quoted-printable and the adoption of base64 is that keeping the two levels
distinct in your mind is *imperative*. If you don't nobody understands what
you're talking about, and confusion reigns.

I haven't looked at this draft in detail, but any restricted encoding mechanism
that doesn't allow encoding of the sequences it usurps isn't worth pursuing.

> Now assume that somebody creates a new company/brand called ph6,
> and wants to register it. It just won't work. And it won't work
> even thought all years long, it would have worked. Who is going
> to explain to the registrant that s/he just draw the short straw?

They have only drawn the short straw in the sense that their domain name won't
display properly without new software. In effect they are in the same boat as
anyone who actually uses the idn mechanism to encode non-ASCII characters.

> And why should we disallow some ASCII domain names? Our goal is
> to allow all kinds of non-ASCII domain names, and it would be
> strange to do that by restricting ASCII.

Not strange at all. We did essentially the same thing in internationalized
message headers, for example.

There is a fundamental tradeoff here. If you start putting characters in the
DNS that didn't used to be part of the accepted repetiore of domain name
characters (AZaz09-), you have the opportunity of getting a nice clean DNS at
the end, but you have a problem with existing software that doesn't expect to
see such characters in domain names. And any such proposal absolutely must
address this issue if it is to be adopted and succeed. There are a variety of
techniques that can be used: Flag days, downgrading, translation layers,
translation records in the DNS, protocol negotiation, etc. and the task will be
to specify how these tools are to be applied in various different cases. Mind
you, I don't expect this WG will write the RFC detailing how to
internationalize email or whatever, but this WG absolutely has to develop
guidelines as part of any proposal it makes that make the construction of such
a document a no-brainer.

If, on the other hand, you refrain from using characters outside the current
accepted range, you have something that is more than a little ugly but which
works with existing applications. 

Now, I'm not arguing that either outcome is what should happen. But there are
downsides to both approaches, and your implicit assertion that the downside
rests solely on the restrict encoding approaches is simply not accurate.

> Of course you could say that whenever a 'real' domain name
> starts with ph6, it is converted. But the converted name
> also will start with ph6, and this will cause endless confusion.

The experience with encoded words in email shows that this is incorrect.
Encoded words have had problems to be sure, but this isn't one of them.
(Indeed, the biggest problem with encoded words by far is that they have been
so successful that they have been used in places where they weren't supposed to
be.)

> While the chances for such registration conflicts are smaller
> than the chances for non-working domain names in the initial
> phase e.g. with an implementation based on UTF-8, I would
> much rather tell somebody 'well, this Japanese domain name
> is something new, and not all software supports it yet, so
> please use this other one if it doesn't' rather than saying
> 'Well, ph6?

I'm sorry, but this dog simply won't hunt. The problem with this "let the chips
fall where they may" approach is that you cannot enforce any sort of separation
between the new names and the old. The new ones will inevitably leak into old
applications, applications that were written in good faith to conform to the
rules at the time, and cause all sorts of mischief. So this ends up amounting
to us saying, "Remember all those old standards we wrote a few years ago where
we said domain names were done this way and it was cool to code accordingly?
Surprise! We lied, and you're screwed sideways until you upgrade everything in
sight!".

The IETF hasn't gotten to the point where it has by treating good faith
implementations and implementors in such a cavalier fashion. And take a look at
where X.400 is these days if you think non-backwards-compatible changes are a
nonissue.

Again, this isn't to say that using UTF-8 or whatever in the DNS is impossible.
It is possible, but it will take a substantial amount of work to make it fly.

> Bad luck, we thought never ever somebody would
> register such a thing.'. With international domain names,
> we are providing something new, and we know that whatever
> the proposal, they won't work from day one everywhere.

Actually, they can. This is one of the nice things about restricted encodings.

				Ned