[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Canonicalization: [28] through [31]
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