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

Re: [idn] Debunking the ACE myth



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

Paul Hoffman / IMC wrote:
> At 11:13 PM +0100 7/19/01, David Hopwood wrote:
> >If, for example, a proposal required upgrading of the authoritative
> >servers *for zones that include IDNs* (but not necessarily any other
> >servers or proxies), I don't see any reason why that couldn't be done
> >quickly. Such zones have sufficient incentive to upgrade, if necessary.
> 
> That's not what most of the proposals at hand require. They require
> that any name server that might do IDN queries be upgraded.

Well, UDNS does. In general it depends on why the servers are being
upgraded. To support labels longer than 63 octets (or names longer than
255 octets), yes, it's necessary to negotiate use of a new DNS version,
which requires updates to all servers in the query path. AFAICS it should
not be necessary to require updates to all servers in the path for any
other reason, though (for example, it is not necessary in order to change
the algorithm by which names as encoded on the wire are canonicalised for
matching against names that come from zone files).

So, I think pretty much any reasonable design could be tweaked to have
the property that names that fit the octet limits in their wire-encoded
form, are resolvable with at most changes to authoritative servers for
zones with IDNs. What, if anything, am I missing?

- -- 
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

iQEVAwUBO1enoTkCAxeYt5gVAQGdPgf/Xf4PKbH6oAtjn/6KzSKO5mWaXS5b6AFn
gdn61hhgVRuCjNzgocJcOfLsVP+5kP1srjJm15uBKv4dnShuw9YQ8YIkDnIOPoPv
yb6OdG9Xm7xFu2K6eeEh0jr7mqGNtNoeSE+6MRovoEI6FBoI7z3e7CdLMP3Ga1SQ
jdz1NAqhbH+wYX3Xv7Mw4d4vBBGjjnHvHEJinOl+DMdd6L43h6ZX5o+hRETI8aMC
H0sSc+jNobyT5hnRjsoHo4NGhA2Ibsnp+JMdAv5rhaseV/pksUR9u9JPjVnuAoyw
Xxg952WzdXFrAJuFKyIOe8sdTXPJKUNBlAxro5uXIq9kilKd7ZNOaQ==
=xEmw
-----END PGP SIGNATURE-----