[idn] iDN Transition Support Requirements

[Dave Crocker <dhc@dcrocker.net>]

What portions of the Internet must support the relevant DNS mechanisms, for 
ACE versus UTF-8?

Let's make sure we have in mind the full set of components that might be 
relevant.  So, here is a rough topology of the generic Internet space, for 
DNS processing:


Client                                  Server
App                                             App

         Client
         DNS

                 DNS                     DNS
                 Srv1                    Srv2

                         DNS Srv1
                         Admin Tools


And application specifics for email:

Mail            Submit          MTA1    List            MTA2    POP 
or          Mail
UA2             Srv                     Expander                IMAP 
Srv        UA2


(Web cognoscenti are invited to add specifics for that part of the 
world.  I hate ascii charts.)


Let look at 2 scenarios:

1.  Minimal use.  Here we want someone to be able to specify an iDN and 
have the associated application make contact with the desired host.  Only 
the requesting user is relevant to this case.

2.  Comfortable use.  This goes beyond Minimal use by also providing some 
end-to-end comfort for the other participating users.



Minimal use, ACE
----------------

a.  Administrative Tools for target DNS name must be upgraded to permit 
adding iDN strings into domain name table.

b.  Requesting user enters the domain name in the 'native' character 
set.  This, of course, means that the application taking the data in must 
support the character set.  This is entirely independent of ACE versus UTF-8.

c.  Application hands the string to the client DNS software.  It therefore 
must understand the native character set and convert it to ACE form.  (One 
might wrap a layer around the client DNS code, to make iDN transparent to 
the client code, but I'm guessing that there is no major benefit; in any 
event, please treat the implementation choice as irrelevant:  some code 
around this area needs to handle iDN strings in native character sets and 
to make it then comform to iDN specifications.

c.  End of list.  No other portions of the system need to handle iDN.  All 
other DNS components behave as always.  Other users might see ugly strings, 
but the strings will not need "interpretation" as iDN strings.  Nothing breaks.


Comfortable use, ACE
--------------------

c.  Other participants' applications must support iDN, though each can be 
upgraded at their own convenience.

d.  End of list.



Minimal use, UTF-8
------------------

a.  same as ACE

b.  same as ACE

c.  Every DNS component through the lookup sequence needs to support iDN, 
before a successful lookup can be achieved.

d.  The target host application must support iDN, if it does any domain 
name processing, such as to comfirm IP address and domain name matching, or 
to display the string in native form.

e.  End of list.


Comfortable use, UTF-8
----------------------

same as Minimal use, UTF8.


So...

ACE permits incremental adoption.  For a first level of utility, only the 
requesting user's software and the target host' domain server 
administrative tools need to be enhanced.  On reflection, it will probably 
seem obvious that one cannot get more minimal than that.

By contrast, UTF-8 does not achieve minimal utility unless and until all 
DNS-aware applications in the processing path are able to support iDN.

Taking a look at the email set of applications, we should note that most of 
them are under independent administrative control.  So that a great many 
independent administrators must ensure their software has been upgraded 
before iDN is useful.  As an example, I'll note that besides having no 
control over the intermediate MTAs, I have no control over the POP server 
software I access.  And then there are all those List servers...


My question then, are:

a)  What technical errors are there in the above?

b)  What guarantees do we have about breakage/non-breakage when UTF-8 is 
received by each of the relevant applications components, or how much 
effort is needed obtain those guarantees?  And please note that the answer 
to the equivalent question, for ACE, is already known:  No breakage.

c)  Unless someone has done a stellar job with a), above, please remind 
me/us why this debate has continued for so long...

d/
---------,-
Dave Crocker  <mailto:dcrocker@brandenburg.com>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464