Re: [idn] proposals and deadlines

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

"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> wrote:
> 
> > No, only until ACE can be deprecated.  This will happen on a per-app
> > basis where it happens, or with entirely new applications that avoid
> > using ACE altogether.  But when it happens, the app should end up
> > with a native UTF8 environment, rather than being stuck with ACE.
> 
> Okay, now let's think about this hypothetical new application that
> uses UTF-8 natively.  It uses UTF-8 to talk to its peers, and UTF-8 to
> interact with the user, data files, etc.  Absolutely everything it ever
> does with domain names uses UTF-8.  Except one thing: DNS lookups,
> which sometimes use UTF-8 and sometimes use ACE.

This hypothetical application would be written to only use UTF8. After a
certain point, it wouldn't make sense to continue writing apps for an
outdated encoding. This wouldn't happen immediately, but once there was a
sufficient installed base, why not? EG, how many new apps are being
written for 7-E-1 parity, or for punchcard storage? After some point, we
should assume that the mere presence of UTF8-encoding will result in some
new application using UTF8 alone, and not supporting a fallback to ACE.

> > Your proposal does not provide this differentiator, and allows
> > corrupt data to enter the query chain on the same footing as
> > legitimate data.
> 
> What do you think my proposal is?

  | Subject: Re: [idn] proposals and deadlines
  |    Date: Sun, 15 Jul 2001 06:00:09 +0000
  |    From: "Adam M. Costello" <amc@cs.berkeley.edu>
  |      To: IDN <idn@ops.ietf.org>

  |     ACE-encode query
  |     look up using oldAPI
  |     ACE-decode response
  | 
  | The latter is less code to write and maintain. I can't see a
  | reason why any programmer would opt for the more complex method
  | given those two choices.  I also can't think of any scenario
  | where an EDNS/UTF-8 lookup failure should not be followed by an
  | attempt with DNS/ACE.  Which means I can't think of a single
  | scenario where a programmer would want to use newAPI at all. 

When you put conversion in the resolver, the resolver will attempt to
convert data that should not be converted.

For example, there are currently applications on the market that will try
to process 8-bit data that is given to them. Because these applications
were written before nameprep, before the IDNS draft, and the other new
rules (which may or may not come about), these applications are guaranteed
to make wrong assumptions.

If this data is passed to oldAPI, and then the resolver says "oh goodie,
UTF8!", converts it to ACE and then pushes it into the query chain,
unexpected results will absolutely occur. Detrimental effects (such as
positive matches for wrong data) are likely to occur. This is particularly
true with applications that try to work with charset data from
locale-based encodings (like 8859-15) or OS-specific encodings (like
Windows-1252 or MacRoman).

Furthermore, the resolver must not perform the conversion because it
doesn't know what the application is going to do with the data. If a
resolver answered in the affirmative to a probe-test, then the application
may wrongly perform a subsequent task (such as an authentication request).

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