Re: [idn] WG last call documents

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

Dan Oscarsson wrote:

> From what I could read the title is wrong.
> It should be: Stringprep Profile for Domain Names.
> 
> To make this work, we need ONE stringprep plus ACE.
> One that can be used on ALL labels in DNS.

We have been through this subject many times. STD13 binary domain names
and i18n host names are fundamentally incompatible. One specification will
not suffice.

> To have different profiles for different labels would be
> a mess. Well, you could mark each profile+ACE with a
> different ACE prefix to indicate profile used but having
> lots of different encodings/profiles have so far proven to be
> a big difficulty for programmers to handle.

I disagree. IDNA only needs to perform encoding and decoding, it doesn't
need to validate the domain names. Validation has ALWAYS been performed by
the participating applications, and has NEVER been performed by the
resolver. There is no reason why a codec should perform this validation.
The profiles are/should-be for the benefit of the applications, the
protocol designers and the data-format designers. The codec should just
convert them.

> I agree in that the WHOIS server should output names using the
> character context of it's protocol.

Are you sure the server should do this and not the client? Well, what if
the "client" is TELNET, should TELNET always do it?

The point here is that EVERY network service has its own considerations.
Demanding that all services implement a user-level feature is absurd. It's
as ridiculous as saying that all text MUST be white-on-black from this
moment forward.

The outcome of this mandate is that every existing specification is made
obsolete and non-compliant. BY A DRAFT! It's arrogant and ignorant of the
ramifications that every network service has different issues that have to
be worked through. Completely absurd.

> Protocol identifiers can have non-ASCII characters.

/etc/services cannot be expected to hold UTF-8 on all Internet systems

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