Re: [idn] Canonicalization: [28] through [31]

[Paul Hoffman / IMC <phoffman@imc.org>]

At 12:43 PM -0400 6/26/00, J. William Semich wrote:
>I think this requires further discussion. Not necessarily true
>canonicalization should be done on the client, IMO. Paul, can you explain
>why you think it should?

There is no such thing as "the client" in this discussion. Going back 
to the chart from the requirements document (everyone on this mailing 
list *has* read the excellent new material in the requirements 
document, haven't they?):

+---------------+
| Application   |
+---------------+
       |  Application service interface
       |  For ex. GethostbyXXXX interface
+---------------+
| Resolver      |
+---------------+
       |     <-----   DNS service interface
+-------------------------------------------+

There are two places for canonicalization to be done before the DNS 
service interface: in the application, or in the resolver. My 
(possibly simplistic) summary of the arguments so far are:

In favor of application:

- Early canonicalization is a cleaner architecture design

- Spending the cycles on the end systems puts less burden on resolvers

- For initial change to IDN, the applications need to be updated 
anyway to handle the new format for the names

In favor of resolver:

- Updating a single resolver provides new service to large number of 
applications and (possibly) users

- It is easier to find canonicalization bugs in resolvers than in 
applications because the resolver has predictable programmatic 
interfaces

- IDN will probably be revised often as new characters are added to 
ISO 10646, so updating smaller number of resolvers is better than 
revising more applications

- When an end user has a problem with resolving an IDN name, it is 
much easier to test if the problem is in the resolver than in the 
user's application

--Paul Hoffman, Director
--Internet Mail Consortium