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

["Martin J. Duerst" <duerst@xxxxxx>]

At 00/06/26 10:54 -0800, Paul Hoffman / IMC wrote:
> 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

Additional point: Easier for people to upgrade if they need.

> 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