Re: Just send UTF-8 with nameprep (was: RE: [idn] Reality Check)

[Patrik Fältström <paf@cisco.com>]

--On 01-07-17 16.48 +0900 Martin Duerst <duerst@w3.org> wrote:

> It is very important to understand that in most contexts, the chance
> that a label is changed (except for lowercasing, which was part of
> the UTF-8 proposal from the start) by nameprep when somebody takes a
> proper domain name from paper and inputs it, is *very* small.

We will have problems when domainnames are registered.

Say that someone send in request for registering domain A which is
correctly nameprepped. If someone else is sending in domain B for
registration which would be nameprepped into A, it is extremely important
that B is not registered, but instead this second person get to know that
B, converted to A, is already registered.

It is enough with only _one_ mistake (regardless of how small the risk is
that this happens) and we will have some definition of chaos.

I also ask myself this the last couple of days:

- This wg is about what is used in the DNS protocol.
- Many people want UTF-8 to be used in DNS.
- Application protocols do not use UTF-8 but ASCII (most of them).
- Someone (in Applications Area) have to write documents, one per protocol
  on how to pass Unicode characters in the protocols, how to handle
  downgrading to something else if needed (like 8BITMIME in SMTP) and
  for each protocol what the downgrade is to.

Conclusion:
- As many application protocols (like SMTP) can not use UTF-8 for a while
  should not DNS use some more efficient encoding than UTF-8 in the
  packets?

I claim that the actual encoding which is to be used in the DNS protocol is
something this wg can not come up with, but instead the DNSEXT wg in the
DNS is the correct group which is to come up with an encoding which is as
efficient as possible, given DNSSEC and other new things which they are
working with.

I further guess that when people in this wg talk about "we want UTF-8" they
really talk about what they want to use in the Application Layer protocols,
but defining that is really out of scope for this wg.

So be careful what you ask for!

Either this wg come up with something which is backward compatible with
other existing standards, or it comes up with a "framework" and give work
items for other wg's and leave it to them for standarization.

  paf