I agree with Martin on this.
Somebody mentioned cultural sensitivity in this (sub)matter.
Well, for those of you that have not suffered through about
a decade of "Q-P" I can tell you that 1) it is culturally
very offensive, and 2) it is still leaking through in raw
even in the most advanced e-mail clients now and then.
No scheme that reencodes non-ASCII into ASCII will ever
be culturally acceptable, since it will, I emphasise: WILL,
leak trough to end users, for all future use, as ASCII text.
And still no-one has even made it plausible that some DNS
servers will 'fall over and die' if presented with 8-bit
data. And if some DNS servers do, then they are so
vulnarable to attack that they should be upgraded or
decommissioned ASAP anyway.
Kind regards
/kent k
> -----Original Message-----
> From: Martin J. Duerst [mailto:duerst@w3.org]
...
> At 11:58 00/01/31 -0800, Paul Hoffman / IMC wrote:
>
> > The new draft has the ungainly name of CIDNUC (Compatible
...
> I had a look at this draft.
>
> Some pretty detailled work, probably rather too much than not enough.
>
> The main problem I have with this draft is that as far as I understand,
> it introduces some restrictions on the current DNS, and/or a flag day.
>
> The problem is the 'ph6' prefix. Whatever the prefix, if we follow
...
> While the chances for such registration conflicts are smaller
> than the chances for non-working domain names in the initial
> phase e.g. with an implementation based on UTF-8, I would
> much rather tell somebody 'well, this Japanese domain name
> is something new, and not all software supports it yet, so
> please use this other one if it doesn't' rather than saying
> 'Well, ph6? Bad luck, we thought never ever somebody would
> register such a thing.'. With international domain names,
> we are providing something new, and we know that whatever
> the proposal, they won't work from day one everywhere.
> Explaining that is not too difficult. Taking away from
> the current infrastructure is a completely different
> thing.
>
>
>
> Based on the considerations above, I therefore propose to
> add a requirement, as follows:
>
> Internationalized domain names MUST NOT restrict the possibility
> for registration of any domain name that could currently be
> legally registered as an ASCII-only domain name, and MUST NOT
> restrict any functionality of any such registration, such
> as display or input.
>
...
> - 3.2: There is no need to mention U+FFFD for displaying undisplayable
> characters. That should be done by the display engine without changing
> character codes.
>
> - 3.3: I don't think we will see editors that work with cidnuc directly.
> Having to convert back and forth for each edit of a zone file will
> be a major pain. For UTF-8 or similar, that would be much easier.
> UTF-8 can be edited today e.g. with Mule (+Mule-UCS) or MS Word,
> just to name two.
>
> I propose to add the following requirement:
>
> It SHOULD be possible to edit internationalized domain names in
> zone files or similar data with widely available text editors.