Re: [idn] I fear I cannot use IDN in the next 10 years

["Eric A. Hall" <ehall@ehsco.com>]

Paul Hoffman wrote:

[overlapping comments and non-responses eliminated]

> >    Let me restate this point, since it is somewhat complex. Although
> >    UDNS supports a dual-mode model, once UDNS (or something similar)
> >    were approved, developers could begin to work on applications
> >    which ONLY used UDNS, without any code for ASCII or ACE.
> 
> You are not talking about the UDNS that is before the WG. That
> protocol *requires* an ACE fallback.

The fallback mode also serves transitional purposes. After the majority of
queries start succeeding, only a minority of queries will fallback. After
a few more years, they all succeed, and there are no fallbacks. Dual-mode
facilitates transition.

> >  While this is technically not a
> >    "requirement" per se, the seamless user-driven transitional
> >    aspects should be requirements. Something very much like UDNS
> >    will be required for this. A "new naming service" is unlikely to
> >    reach critical mass without some kind of backwards compatibility,
> >    which UDNS provides.
> >
> >    Furthermore, the cost of UDNS is incremental to that of ACE,
> >    since they share many common features and functions. If a
> >    developer is going to add ACE support to an application (which
> >    they must do in the short term),
> 
> So, if you admit that here, why did you contradict it above?

There's no contradiction with UDNS providing ACE+UTF8 in the short term
and eventually turning into UTF-8 only.

> >This issue would have to be resolved if we were ever to move beyond
> >ACE. It is beneficial to design for such limits up front, rather than
> >revoking names later which will be incompatible. This is only a cost
> >if ACE and some other service are developed at different times, and is
> >NOT a cost if they are developed together. This is, in fact, a
> >motivating factor for beginning work on UDNS *NOW*.
> 
> Sorry, but I missed the part where you explain how to fix the
> problem. Without a fix, UDNS is dead in the water.

The "fix" that would be required is to define common maximum lengths. This
will be required in any event, and doing it up front makes most sense.

> >  > - UDNS requires more work to be done by authoritative DNS servers
> >
> >Yes, UDNS requires authoritative servers to maintain name mapping
> >information. However, I see this as being a transitional cost.
> 
> And you demand that all of the other people running name servers will
> agree with you.

Versus the ACE-only demand that every application support a secondary
encoding that isn't used anywhere else in the world. Forever.

> >  In the
> >beginning, few clients will support UDNS, but over the course of several
> >years, most clients will support UDNS. At some point (two decades out?
> >shorter?) it should be possible to switch entirely to UDNS, meaning that
> >there will no longer be a need for servers to store both versions. The
> >longer we delay beginning such a transition, the longer it will be before
> >we can complete that transition. If we never start it, we will never
> >complete it.
> 
> In other words, you don't think that making the com/net/org servers
> and the root servers do normalization and mapping is a problem. I
> take it you don't run any of those.

The com/net/org servers don't HAVE to do it. The question of whether or
not sufficient computing resources are available on the market to service
those zones is a question for those admins, not for you or me. I wouldn't
be shocked if it wasn't rolled out on those zones right away.

> >  > - UDNS UTF-8 queries that fail will cause more load on the DNS
> >
> >Yes, it will cause one additional lookup. This is equitable with requiring
> >one extra delegation server in the path. This is not a great cost to begin
> >with. Furthermore, seeing as how it is also transitional, it will only be
> >a cost for the short-term, and will not be a cost after a few years.
> 
> You blithely double the load on the DNS during the "transition". Nice.

It's only doubled if every lookup fails. Where would this load come from?
Are there going to be URLs with non-existent IDNs floating around that
users will always try to follow with their non-existing apps? Please.

Most of the early delegations will result in failed queries. Once
compliant apps were released and servers were deployed, less queries would
fail. Eventually the load will return to normal. At some point it shifts
from fallback-to-ACE to don't-fallback-it-worked, and that shouldn't be
impossibly far away.

The sooner it is started, the sooner we will finish, anyway. Better to do
it now than to do it 10 years from now when the loads are higher.

> >  > - Applications that implement the UTF-8 part of UDNS have to handle
> >>  the inevitable errors that come from queries that bounce, have to
> >>  recast those queries in ACE (assuming that the name is even legal in
> >>  ACE, which some won't be), and then have to emit those queries again,
> >>  causing more DNS traffic
> >
> >As with the other issues, this is a transitional cost which dissipates as
> >deployment goes up.
> 
> Wrong. It is with us as long as there are current applications running.

And they will always be with us in their current form if we go with
ACE-only. Do we really want to be designing for ARPANET forever? At what
point do we start thinking about laying the necessary groundwork for
migration to eight-bit technology?

> >  It is a cost in the beginning, but it is not a
> >significant cost after a few years.
> 
> First you said "twenty", now it's down to "a few". Some of us think
> there is a difference.

What I said was that ACE mode could be disabled in twenty years if not
sooner, when the transition is complete. Processing a "significant number"
of failovers should only be an issue for a few years, until the common
case is UTF-8 success. These are different scenarios and they have
different timetables.

> >  > - The errors caused by UTF-8 queries are the same as other legitimate
> >>  DNS errors, meaning that applications will have to have their own
> >>  (probably-nonstandard) logic for differentiating between expected
> >>  errors and real errors
> >
> >Because UDNS is an applicaton of EDNS, it uses the EDNS error codes. My
> >experience is that these codes are farily simple to work with.
> 
> You have misread UDNS, then. The query errors from un-upgraded
> servers will not be EDNS errors: they will be format errors from the
> current DNS.

No, they aren't different. The same errors that EDNS is intended to
trigger should be the errors which UDNS triggers. If this doesn't work
with UDNS, then it won't work with EDNS either.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/