RE: [idn] compatibility chars in draft-ietf-idn-nameprep

[RJ Atkinson <rja@inet.org>]

At 13:48 16/08/00, Paul Hoffman / IMC wrote:
>At 1:35 PM -0400 8/16/00, RJ Atkinson wrote:
>>At 12:23 16/08/00, Paul Hoffman / IMC wrote:
>>
>>>Just to be clear, this is saying that the user interface can allow any input (which is the IETF way of doing things), but it MUST NOT pass any character that has a compatibility equivalent to the *input* of the nameprep step. Is this what folks are agreeing to?
>>
>>        I don't understand your proposal in sufficient detail
>>to answer yes or no.
>>
>>        I think that mundane applications using the network
>>OUGHT NOT to have to know much about DNS rules, which specifically
>>means that I think it would be reasonable for some random application
>>to pass a prohibited character into the DNS resolver library's API.
>>
>>        It would then be an implementation choice whether that
>>particular resolver library converted the prohibited character
>>into the fully equivalent legitimate character (with or without
>>notification to the application) or whether it returned an error
>>(with or without details on which character was prohibited).
>
>If the name preparation was being done in the resolver library, then the proposal to prohibit characters with canonical equivalents would not match your scenario. If the name preparation was done in the DNS servers, then the proposal would match your scenario.

I believe that name canonicalisation/normalisation needs to be done 
in the resolver library because distributing the computational load 
is the only approach I see that obviously scales well to the global
Internet, which is our scope here.

I'm happy to be educated why another approach would scale, but would
want to see a fairly detailed technical rationale before I changed
my perspective.  No one seems to have offered such a rationale
the past few times I've made this comment, but I'm still open to
hearing one.

>This is why I'm being so picky here: it depends on where we do name preparation. The proposal to ban characters with compatibility compositions on input to the nameprep step is in contrast to the proposal that we were discussing, which would allow them as input to the nameprep step but prevents them from getting to the output. Both proposals would have the same result, but obviously have different characteristics for the user and the creator of the nameprep software.

Precision and clarity are both useful here.

Ran
rja@inet.org