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

["Eric A. Hall" <ehall@ehsco.com>]

Internet-Drafts@ietf.org wrote:

> Title    : Internationalizing Domain Names In Applications (IDNA)

This is really close to being a simple codec. The expanded character
repertoire and the removal of the mandatory transliteration "requirement"
is helpful, as those were both big problems. However, the text still
presents some of these issues:

 | 6.4 Avoiding exposing users to the raw ACE encoding
 | 
 | 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 rule still requires transliteration. As has been discussed
extensively on this list, this will cause problems with data-types which
must never be transliterated. Also interesting that a recent discussion on
the ietf-822@imc.org mailing list showed that email people prefer to see
the encoding form directly, rather than the original value (at a minimum,
this means that users have one preference while admins have a different
preference, and that these are different). Also interesting that the URI
i18n draft is specifically avoiding the use of transliteration.

In light of those facts, I will repeat my multiple earlier statements that
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,
even though the authoritative parties don't want it.

 | 1.1 Brief overview for application developers

 | IDNA requires that implementations process input strings with Nameprep
 | [NAMEPREP], which is a profile of Stringprep [STRINGPREP], and then
with
 | Punycode [PUNYCODE]. Implementations of IDNA MUST fully implement
 | Nameprep and Punycode; neither Nameprep nor Punycode are optional.

IDNA needs to be available as a generic codec for use with any profile of
stringprep that works with domain names. If another WG needs to develop a
stringprep profile (eg, Kerberos), they should not be required to develop
another encoding syntax.

As such, 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 which requires
conversion."

Very close otherwise.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/