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

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

"Eric A. Hall" <ehall@ehsco.com> wrote:

>  | All applications that might show the user a domain name obtained
>  | from a domain name slot, such as from gethostbyaddr or part of a
>  | mail header, SHOULD be updated as soon as possible in order to
>  | prevent users from seeing the ACE.
>
> this text should state that transliteration MUST NOT occur unless
> the governing protocols and/or data-types specifications explicitly
> allow it.  The text as written above is an implicit update to these
> specifications,

There is a rule that *requires* the ASCII form to be used in all legacy
protocols and data types, and that rule explicitly overrides the rule
about hiding ACEs from users.

IDNA does not recommend altering protocols or data types in any way; it
recommends altering user interfaces.  That is what the text you quoted
is doing.

Applications are welcome to allow users to set their own user interface
preferences.  For example, most mail applications hide most header
fields by default, but allow users to see the full header if they want.
This is the same sort of thing.  Show the non-ACE form by default, and
allow users to see the ACE form if they want.

> the dependancy on nameprep should be lightened, perhaps saying "the
> IDNA algorithms are specifically designed for use with nameprep but
> can be used with any suitable stringprep profile

A Stringprep profile suitable for use with domain names would have to be
equivalent to Nameprep-followed-by-additional-prohibitions.  Otherwise
names wouldn't compare correctly when they moved between applications
using one profile and applications using another profile.

Therefore, it is correct to say that Nameprep is mandatory for IDNA.
The specialized versions that you envision would still include Nameprep,
even if it's disguised as part of a larger Stringprep profile.

AMC