[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 20:36 01/07/17 -0400, Keith Moore wrote:
> > At 12:24 01/07/17 -0400, Keith Moore wrote:
> > > > As I have remarked earlier, we don't need this WG to allow
> > > > people to create random domain name labels. ACE is not
> > > > 'domain names just as they are'. It's a clear layer violation.
> > >
> > >ACE is an *encoding" just like UTF-8 is an *encoding*.
> >
> > Sorry, no. ACE can be reapplied to ACE (the drafts of course prohibit 
> this),
> > but please try to apply UTF-8 to UTF-8.
>
>I fail to see how this is relevant.

Architecturally, because it's folding one layer back onto the same layer.
Operationally, because some implementations will get it wrong, and we will
see ACE over ACE the same way we have seen Mime over Mime.


> > Also, ACE is used piecemeal.
>
>That's true.  ACE is an encoding, but is not a general purpose encoding.
>It's designed for a narrow but important purpose, and it's sufficiently ugly
>that you really would not want to use it except when necessary.  But there
>are cases where it is necessary.

What I see comming more and more is that this 'narrow but important'
argument will be applied over and over: It's not worth to do anything
to upgrade protocol A because the DNS is ACE, then it's not worth to
upgrade protocol B because protocol A uses ACE, and so on.

If for example the IDNA draft could say that resolvers should provide
a way (a new API) to resolve UTF-8 directly, and could say that UTF-8
(nameprepped) is accepted as an alternate encoding for zone files and
is preferred where possible, that would help quite a bit to avoid forcing
protocols and operations into ACE unnecessarily.

What do you think of it?


Similarly for the DNS protocol: Send UTF-8, and if it's not found,
try again with ACE. An existing DNS server with no IDN names (in
whatever encoding) that behaves in any other way than returning
'unknown' for UTF-8 is definitely broken and has to be fixed anyway
(and I'm still really and seriously looking for somebody to give
an actual report on such a case).

I agree with you that when thinking about whether it's worth to
do a dual implementation in a DNS server, it looks like a pure
overhead, and just looking at DNS, it is. But overall and in the
long run, it's not an overhead, it's an investment. The past is
important, but the future is more important than the past.

Regards,   Martin.