Re: [idn] proposals and deadlines

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

> You said that in your proposed architecture, if the EDNS/UTF-8
> lookup fails, then there is a fallback to DNS/ACE (at least in some
> situations).  At first, I assumed that the fallback would happen inside
> the resolver, but then you said it wouldn't, so that means the fallback
> must happen inside the application, right?

It has to, since each application (or more accurately, each usage) will
have its own behavioral considerations.

For example, a mail client may allow users to specify the SMTP and POP3
servers by using UTF8 IDNs. This doesn't affect the protocol operations,
but instead only affects the lookup of the server's IP address. A fallback
to ACE can be expected for this lookup operation, but this doesn't affect
the protocol, and the resulting ACE IDN would not need to be rendered by
the client anywhere.

Conversely, the same mailer may keep an address book containing UTF8 IDNs.
Without some sort of extension to SMTP, those addresses will have to be
converted to ACE whenever they are written into the envelope or whenever
they are written into the message headers. If a UTF8-envelope extension
mechanism is created, but it fails to negotiate, then presumably LDH rules
will still apply, so conversion will have to take place in the
applicaiton. In this example, the option negotiation has failed, but no
lookups have failed.

Assuming that the option negotiation succeeds, the SMTP server will
eventually need to log the connection for a Received header. Obviously it
speaks UTF8 if the option was successfully negotiated, so it could try to
use UTF8 for the PTR lookup, although the default behavior should be to
use LDH (ACE), using the legacy API calls. We can also assume that if the
EDNS PTR lookup fails, then it would have to fallback to ACE.

Once mail arrives, the recipient system may need to convert UTF8 envelopes
back to ACE, or if the local message routing maps are using UTF8 IDNs,
vice versa.

That is four conversion scenarios: 

   o A RR lookup failure
   o extended-envelope-option negotiation failure
   o PTR RR lookup failure
   o message routing lookup

As can be seen from the above, each usage will need its own rules, only
two of which use DNS, and two of them have to be defined by an external
protocol (UTF8 in Received headers). As such, the applications have to
manage the conversion process.

> In other words, you expect these applications to include code that
> looks like this:
> 
>     start with a UTF-8 query
>     look up using newAPI
>     if that failed then begin
>       ACE-encode the query
>       look up using oldAPI
>       ACE-decode the response
>     end
>     finish with a UTF-8 response

No, I am thinking:

      start with a UTF-8 query
      look up using newAPI
      if that failed then do whatever they are supposed to do next

> But they could instead use code that looks like this:
> 
>     start with a UTF-8 query
>     ACE-encode the query
>     look up using oldAPI
>     ACE-decode the response
>     finish with a UTF-8 response
> 
> The latter starts and ends with UTF-8 just like the former, but
> is smaller and simpler.  You were recommending a fallback to be
> used sometimes by some applications, and my point is that for those
> applications it's easier to just use the "fallback" all the time.

I think this is a really creative idea, but as illustrated, the onus of
conversion is on the applications and their protocols just as much as it
is on DNS. Even though we could do this for the DNS parts, the
applications will still have to perform conversions. This would be
somewhat easier on the server infrastructure, but it wouldn't save the
applications any labor, and would simply move the server's burden to the
resolver's side of the fence.

There is also a technical consideration here, in that this approach does
not provide a way to distinguish between spurious 8bit data and IDNs. An
older application that encounters an 8bit domain name may pass it into the
stream when it shouldn't (there is at least one application out there now
that passes UTF8 into the DNS). With the dual-message model, at least we
can tell that this is an old client and the malformed data can be compared
to LDH and rejected, while EDNS messages should only be coming from
modernized applications that (hopefully) follow the normalization rules.
This flag is required for Internet stability, IMO.

More importantly (to me anyway), this approach does not provide a
migration path to a UTF8-aware DNS infrastructure. We would still have to
store the raw zone data in ACE format, we would have to invent ACE
editors, we would have to educate the administrative masses on ACE
encoding syntax, and there would be less impetus to move to UTF8
end-to-end in higher-layer protocols. We should be helping to make the
network truly internationalized with this work, IMHO.

> If you want to help these applications to forget about ACE, you can do
> that by hiding the fallback mechanism inside the resolver.  Then the
> application can simply do:
> 
>     start with a UTF-8 query
>     look up using newAPI
>     finish with a UTF-8 response

The unique message is the flag; the API just provides a separate access
point for the message.

> AMC

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