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

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

[thanks paf]

on 6/10/2002 1:58 AM Patrik Fältström said the following:

> The problem is not capitalization. If you ask for preservation, you should
> ask for preservation of the original string. Just looking at case
> preservation is a very very tiny issue.

Yeah, can I have preservation? Normalization will also vary.

> And, caches will have issues with it, and the compression algorithm and...

Some of these issues are showing up in the conversion work too, as you can
imagine. They give me headaches. EG, when you change an owner name from
UTF-8 to ACE, the converting system needs to find all of the compression
pointers which refer to that owner name and then expand/relocate them.
This can be handled through a mix of features -- compression-specific EDNS
label types for one -- and this can work without the converter having
intimate knowledge of the record structure (only the owner names will be
converted). If I can solve that, then I have also solved one of the big
problems with STD13 domain names at the same time.

I am planning to minimize the risk of collisions by prohibiting sister
owner names from being entered which would collapse to the same domain
name. Although this isn't technically required, better safe than sorry.
The rule can be relaxed later if it proves unnecessary.

> So, the result was that at the end, we always to conversion of strings when
> they go "into the system" of application and DNS protocols. Within that
> world, that f(X) is what is used. Period.

Yeah, I understand the need for it, and I support it for the common
scenario. But we also need to offer this capability if we want people to
not invent STD13 octet interpretations.

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