"Adam M. Costello" wrote: > > "Eric A. Hall" <[EMAIL PROTECTED]> wrote: > > > The profiles do not have to be subsets of nameprep. Case variance and > > character variance are both likely to occur. > > If one application is using Nameprep and another application is using > some other profile with different normalization or a different mapping > table, then there are going to be pairs of names that match according to > one application and don't match according to the other. What good can > come of that?
There is no reason that such a scenario must occur. Applications can and do define their own domain name syntaxes (localpart is different from hostnames, is different from SRV, is different from NetBIOS, is different from Kerberos, and so forth). There is no reason to believe that this scenario will not continue into the future. Under the current wording, all of the applications must use the nameprep rules to use IDNA encoding, even if those rules are not applicable to the application at hand. > "Eric A. Hall" <[EMAIL PROTECTED]> wrote: > > > If we embraced the robustness principle, they would look at the spec > > and say "MUST NOT do conversion" and they would break nothing. > > > > > Having the specification mandate UI behavior seems out of place to > > > me. > > > > That is exactly what it does now: SHOULD transliterate anything that > > looks like an ACE domain name. > > "SHOULD" is less of a mandate than "MUST NOT", RFC 2119: | 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there | may exist valid reasons in particular circumstances to ignore a | particular item, but the full implications must be understood and | carefully weighed before choosing a different course. It is not any less of a mandate for the normal case. The normal case is precisely the scenario I am worried with. > and we leave a big escape > hatch: "except when the use of the non-ASCII form would cause problems > or when the ACE form is explicitly requested". IE, people can break stuff all they want until the authoritative body says to stop it. That is exactly the wrong approach. -- Eric A. Hall http://www.ehsco.com/ Internet Core Protocols http://www.oreilly.com/catalog/coreprot/
