Re: Who does what (Re: [idn] San Diego Meeting Notes)

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

> What is the opinion of the working group on IDNA vs. IDNRA?  Paul and
> Patrik have proposed two alternative ACE implementation approaches:  IDNRA
> calls for an application and resolver-based approach, putting most of the
> IDN work in the resolver, while IDNA calls for an application-only approach.

I don't think there's much difference between the two; IDNA is just a 
cleaner way of expressing what would end up as more-or-less the same 
architecture as IDNRA.  Here's why:

- since ACEs are compatible with ASCII domain names, a resolver API 
  that accepts and returns ACEs already exists; it's not going to
  go away anytime soon even if other resolver APIs accepting and/or
  returning UTF-8 were to appear.

  even if the resolver API always accepts and returns ACE, there will
  inevitably be wrapper routines around the resolver which perform
  simple kinds of lookups and which accept and/or return UTF-8.  

  so either way, we'll have one interface that deals in terms of ACE 
  and another that deals in terms of UTF-8.  the only real question
  is the degree to which the latter interface will be consistent across
  different platforms.    if not, folks writing portable software
  will need to supply their own conversion routines.  however, the
  algorithms (and probably code) to do this will be published, so 
  even this isn't a huge barrier.

- many applications will need to compare IDNs with one another for 
  equivalence.  for reasons of backward compatibility they will see
  both ACE IDNs and UTF-8 IDNs, and they'll have to know whether
  they are equivalent.  in addition, applications will have to 
  convert from UTF-8 format to ACE when IDNs are used as elements 
  in protocols which do not (yet?) tolerate non-ascii DNS names, 
  and they'll have to convert from ACE to UTF-8 for display.

  so either way, there will need to be direct access to the nameprep
  and ACE<->UTF-8 conversion routines. they cannot merely be embedded
  in the resolver API.

so either way, you have pretty much the same set of interfaces, and
the same kind of layering.

Keith