"JFC (Jefsey) Morfin" <[EMAIL PROTECTED]> wrote: > > Nameprep is technical, not policy. > > True. And this is why nameprep should technically support policy > decisions under the form of parameters.
I can see that Nameprep and policy restrictions *could* be integrated into a single framework using parameters, but I don't see why they *should* be. We'd have to complicate the Stringprep/Nameprep model to accomodate a wider variety of filtering techniques (and we'd probably still fail to accomodate everything that the registries want to do), and we'd have to distinguish between the standard parameters that all clients must know and use to check syntactic validity, versus the private parameters that registries use internally to check admissibility. While we need a standard for which labels are syntactically valid, I see no need for any standardized algorithm for testing which labels are admissible into a given registry. Obviously syntactically invalid labels are inadmissible for all registries, but each registry can use any algorithm it likes to make additional labels inadmissible. That algorithm may or may not bear any relation to Stringprep/Nameprep, and I don't see why the IETF should care. Notice that the current DNS standards do not define any mechanisms for checking labels for admissibility, and yet registries can (and do) perform their own checks if they want. I don't see why this model should change with the introduction of IDNA. AMC
