[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



I think we should leave this discussion to the proposal. I am okay with Paul's
amendement, ie.

"The protocol MUST specify canonicalization, and the canonicalization 
SHOULD be done before the request enters the DNS service interface."

We should allow proposal to choose where to put it and of course, they have to
explain why.

-James Seng

RJ Atkinson wrote:
> 
> At 11:52 26/06/00 , Paul Hoffman / IMC wrote:
> >Not really. The requirements document has the following (editied for clarity):
> >
> >+---------------+
> >| Application   |
> >+---------------+
> >       |  Application service interface
> >       |  For ex. GethostbyXXXX interface
> >+---------------+
> >| Resolver      |
> >+---------------+
> >       |     <-----   DNS service interface
> >+-------------------------------------------+
> >
> >"Before the DNS service interface" could mean "in the application" or "in the resolver". I do not believe that this WG has come to consensus on this. Thus, I very carefully worded my proposed sentence to say that the canonicalization happens before the DNS service interface, but to limit which of the two places it might be. The protocol must pick one or the other, but it is too early to say which.
> 
>          Putting it in the application is inherently broken because numerous
> existing deployed applications that aren't going to change anytime soon
> and will remain deployed do not perform canonicalisation at present.
> Relying on software known not to perform i18n canonicalisation to perform
> canonicalisation leads to chaos and can't be interoperable.
> 
>          So I do not believe that requiring canonicalisation be performed
> by applications is technically a valid choice.  I believe the only
> two technically feasible locations are inside the DNS client resolver
> or in the DNS server (including caching servers).
> 
> If folks want to disagree with my conclusion, please explain in detail
> how interoperability is maintained in the presence of these existing
> applications that do not perform canonicalisation and won't change
> any time soon (if ever; some are binary applications that are deployed
> but do not have any active development and do not have source code
> available).
> 
> Ran
> rja@inet.org