Re: [idn] One profile for domain names, or many?

[John C Klensin <klensin@jck.com>]

Let me add one bit of clarification to this (again, I don't
think Eric and I are in complete agreement, but we seem to see
some of the same requirements and solutions)...

--On Thursday, 13 June, 2002 03:13 -0500 "Eric A. Hall"
<ehall@ehsco.com> wrote:

> on 6/13/2002 12:49 AM Adam M. Costello wrote:
> 
>> Suppose the IETF were to issue a clarification of the DNS
>> spec stating in no uncertain terms that bytes 80..FF in
>> domain names must match exactly, and that there is no
>> standard interpretation of those bytes as characters (not for
>> any existing DNS services anyway).  Then I wouldn't object if
>> applications that don't like Nameprep were encouraged to use
>> 8-bit names in DNS for non-human-oriented purposes.
> 
>> Eric, would you be satisfied with that?  What do other people
>> think of that idea?
> 
> I've given this some thought, and I think it's a creative
> approach. But I don't think it's the right approach, since it
> only ingrains some of the problems. I know you don't want to
> hear this but it would actually make much more sense to do the
> exact opposite, which is to prohibit eight-bit for the
> standard RRs (which is also what John was saying I think) and
> to embrace and encourage the use of multiple profiles in the
> i18n namespace.

As I indicated in one of my recent long notes, I'd like to make
sure we can define new stuff (certainly Classes and probably
RRs), with different rules.  Examples:

	-- All upper case, with other characters being
	prohibited.
	
	-- Case-dependent matching of ASCII (i.e., lower and
	upper case are different) as well as everything else.
	
	--  True binary labels, with no per-octet interpretation
	(needed for compressed UCS-4 as well as for numeric
	labels).

Now, I'm not sure that we will ever need or want any of these
things (although some of Eric's examples point strongly in that
direction.  But I think anything that we do now --whether an
overbroad statement about IDNA applicability or the (I believe
misguided) text in 2181-- that permanently eliminates our doing
any of the above except by an incompatible change, has few of no
advantages and many disadvantages.

And, yes, I share Eric's belief that strong data-typing and data
type identification leads to better protocols and more
interoperability when it is most important.

    john