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

Re: [idn] I-D ACTION:draft-ietf-idn-idna-08.txt




"Adam M. Costello" wrote:
> 
> "Eric A. Hall" <ehall@ehsco.com> 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" <ehall@ehsco.com> 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/