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

[Keith Moore <moore@cs.utk.edu>]

> > > >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.

I'm not convinced; the cases aren't even similar.  MIME was designed
to be applied recursively, so it's hardly surprising that it's
used in this way.  ACE is designed to be easily distinguished from non-ACE
forms, so it seems unlikely that implementors will accidentally re-encode
an ACE very often.  The closest thing to ACE is RFC 2047 encodings,
and I've never seen one of those recursively applied except as an example
of what not to do.  

Also, I assume that the WG will produce one or more high-quality reference 
implementations of the chosen ACE - actually I'd regard that as essential.  
So it won't often be necessary for folks to implement it from scratch.

> > > 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.

I don't know where you're seeing that argument - I haven't seen it at all.
But even if it's true to some extent, it says nothing about whether
applications will get upgraded and therefore it says nothing about 
whether users will be able to use IDNs in their applications.  They are
completely separate issues.  If anything, the appearance of ACE in
legacy appliations will drive deployment of IDN-aware versions of those
applications.

I do think that most widely-used legacy protocols will get upgraded - 
but on their own schedules, depending on the additional perceived 
utility in doing so, the perceived difficulty of doing so, and also
depending on what other demands there are that the protocol get updated.
And the last thing we want from an operational perspective is for
large numbers of protocols to get updated concurrently - producing
the maximum disruption.
 
> 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?

Regarding the API, I've always assumed that an API to resolve UTF-8 
IDNs was essential.  As for zone files, I've already proffered a suggestion 
to have an exchange format (using ACE) distinct from the native 
format.  The native format could use UTF-8 if that were the platform's 
native charset.  But we shouldn't presume that all platforms will use 
UTF-8.  A separate UTF-8 exchange format, or a way of labelling
native format to say that it is using UTF-8, might also be a possibility.

> Similarly for the DNS protocol: Send UTF-8, and if it's not found,
> try again with ACE. 

no, that's simply not acceptable.  DNS queries are already too 
slow and too unreliable, and you've just introduced some very 
interesting failure modes.

> 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. 

okay, but what's the return on the investment?  it appears to be 
purely psycological, since using UTF-8 on the wire in DNS doesn't 
make it any easier to upgrade either applications or protocols to 
use UTF-8 natively.    you could argue that it reduces complexity
in the long run, but the day that some benefit will be derived
for that reason is decades away.  and by then we should have
upgraded DNS (for other reasons) anyway.

Keith