Re: [idn] comments on IDNA-04

[David Hopwood <david.hopwood@zetnet.co.uk>]

-----BEGIN PGP SIGNED MESSAGE-----

James Seng/Personal wrote:
> David Hopwood wrote:
> > ToASCII doesn't convert to ACE. It converts to ASCII (in particular,
> > if the string contains only ASCII characters, the result will not be
> > ACE).

I should have said: will contain no ACE labels.

> It depends how you define ACE right? :-)

An ACE label means a type 00 domain label that consists of the ACE tag and
an output of the ACE encoding algorithm.

[...]
> > > # ToASCII consists of the following steps:
> > > #
> > > #    1. If all code points in the sequence are in the ASCII range
> > > #       (0..7F) then skip to step 3.
> > >
> > > Step 1 seem to be optimization, but not a required step.
> >
> > It is required.
> 
> Why is it required? Step 4 repeat its again. Step 2 [NAMEPREP] only
> effect on ASCII input is case folding.

Not so: it also disallows some code points (including non-LDH ASCII).
Step 1 definitely changes the algorithm, so it is not an optimisation.

In fact the ToASCII algorithm appears to be incorrect, i.e. not what
was intended, for two reasons:
 - by calling nameprep, it disallows general domain names (i.e. not
   hostnames) that contain both octets >= 0x80 and octets that
   represent non-LDH ASCII.
 - it removes case information before applying ACE encoding - so case
   annotation cannot be done. The only way to specify case annotation
   rigourously is for the case bit of each character to be an output of
   nameprep.

> > Is there any particular reason to reserve the possibility of this
> > being a suffix? The space of names with "xx--" prefixes has already
> > been reserved, in the sense of warning registrars that it may be
> > used for IDN.
> 
> Is there a reason that it *must* be in the form of prefix "xx--"?

No. However, since it is almost completely arbitrary, and several drafts
have used "xx--", why change to something else?

> Why not suffix --xx or a "x-" prefix followed by "-x" suffix?
> 
> What if we cant find an common "xx--" prefix according to aceid process?

I think that's unlikely.

> I feel that the selection of a final ACE tag is an IANA decision.

It's pointless for IANA to do this, because all of the current proposals
call for only one ACE. IANA's role is to handle registration where there
is an ongoing requirement to assign "numbers"/identifiers from a defined
set of alternatives. It doesn't choose what the set of alternatives is,
and there is no need to involve it in one-off decisions that can just
as easily be taken by working groups.

> > I don't think this is a good way of handling zone files, but I do
> > think that the zone file format is entirely within the scope of an IDN
> > proposal (as a format for zone transfers and for interoperability
> > between different server implementations, not as the required
> > representation of a zone). This is how IDNA-04 handles it - by
> > requiring ACE in zone files.
> 
> It is a mistake to standardized zone file format in the first place.

I disagree. The actual format is perhaps a little ugly, but there is
nothing wrong with the idea of a standardised text-based format.

> What if I am using a DNS server which do not have a zonefile but it is
> stored in database?

That works fine; the zone file format is not a required representation,
and no-one is suggesting that it should be. However, suppose you want to
migrate a zone to a different server implementation: if there is a
standardised zone file format, then you can export your existing database
to that format, then import it to the new database. If there is no
standardised format, then you have an n:n database conversion problem.

- -- 
David Hopwood <david.hopwood@zetnet.co.uk>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv

iQEVAwUBO/q2/zkCAxeYt5gVAQHn4AgAkO7VkTj81GiUzX4v3ObHtDI0/BcuA0gx
vfv+APbuV7iTPfT7aRXr3P3PzmhxScscLK2hu6MiQpvg5o40G4iDdKxYVJkbRtoH
567rX0qaQySeoSAKZqBCMTk8EMmO5flhayRwr5bqvPnfKUPyaD8pqaW86lKEs7I+
Ei5BcB+01K5e2YKKmhpwqvcGhHeivXSpM+9DO9rYs8iqpYQt/3HCOwdKl7plwRq9
+N5aID5OO6TRC7MbTDtRqMbX41nDubnpu/walkA7QsgwZOx7rpcO8y4vZbPNORVG
wkUw2v9appDWPrAADDkDp4uY2BefVoScg49ntS3Z/1JTH4dsrFH7tw==
=iPFW
-----END PGP SIGNATURE-----