Re: [idn] New draft: draft-ietf-idn-idna

[Keith Moore <moore@cs.utk.edu>]

comments on draft-ietf-idn-idna-00.txt

overall, I think this is not only the right approach, but the only
viable approach.  so consider these comments in light of that.

I.  Abstract and elsewhere: "...requires no changes to any DNS server"

my guess is that people will want to enter domain names in zone files
using their favorite text editors and their local character sets.
if DNS servers are to understand these, they must nameprep and RACE
such zone files before storing them in internal format.  for some
languages or zones, there might also be a need to enter multiple 
records with variant spellings (e.g. with or without accents)
corresponding to a single record in the original zone file.

I can see two approaches:

1. make DNS servers able to understand IDNs in zone files
   (meaning that they can understand local charsets, and are able
   to perform nameprep, RACE, and variant spelling processing on 
   such zone files.  this probably also implies the need to have 
   a charset label in the zone file)

2. keep zone files in ASCII and say that any nameprepping, RACE,
   etc. conversions that are applied to the original need to be 
   handled in a separate preprocessor.  but will IDN zone source
   files then be in a nonstandard format?

whichever approach is taken - to extend the zone file format or not -
needs to be documented.

(oh sorry...you do say which in section 3.  but you might want to
point out the need  for a preprocessor to convert from local form
to nameprepped-RACEd form.)

at any rate there's probably a need for error checking in zone files to
make sure that RACE encodings are valid. cf. my comments on section 5.


II.  section 2.1.1

Even IDNA-aware applications MUST allow RACE input, because they may be 
passed RACE names from other applications, or from human users.
nameprepped RACE names are valid domain names, and should be treated
as such, even when not input or displayed optimally.

III.  section 2.1.2  

> An IDNA-aware application that is resolving a non-internationalized host 
> name parts MUST NOT do any preparation or conversion to RACE on any
> non-internationalized name part.

the way to solve this problem is to define nameprep and RACE in such a way 
that the nameprepped and RACE-encoded form of a normal ASCII label is 
identical to the ASCII label.

>  Typically, the IETF does not standardize APIs, although
> it has for IPv6. This protocol does not specify a specific API, but
> instead specifies only the input and output formats of the host names to
> the resolver library.

IETF does sometimes define APIs (even if they're not standardized),
and IMHO it would be extremely beneficial if this WG were to define
an APIs for (a) conversion from an IDN (in local charset)
to a nameprepped,RACE-encoded name (b) conversion of a RACE encoded
name to a string in local charset, and (c) DNS query using an IDN
directly (in local charset, returning responses in local charset).

that could be in a separate memo, but it would be better if most 
platforms implemented the same interface for this than if each 
platform had to define the interface for itself.

IV.  section 2.1.3  

> (UTF-8 and UTF-16 are
> likely candidates for almost any operating system, and script-specific
> charsets are likely for localized operating systems).

I would delete this, as it's debatable, and the text seems unnecessary.

> If a signalling system which makes negotiation possible between old and
> new DNS clients and servers is standardized in the future, the encoding
> of the query in the DNS protocol itself can be changed from RACE to
> something else, such as UTF-8. The question whether or not this should
> be used is, however, a separate problem and is not discussed in this
> memo.

I would reword this to say: 

It is possible that in a future a system will be developed to allow 
DNS clients and servers to negotiate use of non-RACE-encoded 
(e.g. UTF-8) labels in DNS queries and responses.  The specifics of such
negotiation and the specific encoding to be used are not defined at 
present and are for further study.

(not sure why I like my wording better...the original just seems awkward
to me)

V. section 2.1.4

this seems overbroad.

I don't think it's appropriate to unilaterally place a SHOULD requirement
on all applications to prevent users from seeing the ACE.  displaying an ACE
will often be better than not displaying any domain at all.  and there are 
contexts where ACEs must be used - such as in email headers.

also, if an IDNA-aware application can't display a particular name
(perhaps because a font for that language isn't available)
it is probably better off displaying the ACE than displaying gibberish
or refusing to display the name at all.  at least the ACE can be 
reused in other contexts.

even if an ACE can be displayed properly, this may be of little value
if the users' applications don't support input of ACEs.

I would either remove this section entirely, or reword it to say that 
applications are encouraged to provide support for input and display of 
ACEs as soon as possible.

it may be that there is a need for a way to map "ugly" RACEs onto
less-ugly, but still ASCII-only names, to be used by applications
that (because of display limitations or whatever) cannot display
much besides ASCII.

VI.  section 5

there's  another possible security consideration - if RACEs can be used
to encode pure-ascii labels then it becomes possible to have an 
alternate set of DNS records for a particular domain - one of which 
is keyed by the RACEd name and another of which is keyed by
the ASCII name.  

and if a RACEd ASCII name is returned in a response to a DNS query
(say in an NS or CNAME or MX record), will the application decode
the RACE and then use the decoded form in a subsequent query, or will it
use the RACEd name in that query?

applications should probably be required to check for bogus use of
RACE - any response that could not have been the output of the
RACE encoder should be considered illegal and should cause an error.

Keith