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
[EMAIL PROTECTED]
