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

["Martin J. Duerst" <duerst@w3.org>]

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