Re: [idn] Adding "optional" characters in draft-ietf-idn-nameprep

[Paul Hoffman / IMC <phoffman@imc.org>]

At 8:18 PM -0400 8/13/00, Keith Moore wrote:
>  > >I don't see this.  The fuzzy matching could happen on a per-label
>>  >basis.  Servers shouldn't be doing any fuzzy matching for a zone
>>  >unless they're authoritative for that zone.
>>
>>  Exactly right. The servers for .com would have to do it for every SLD
>>  under .com, and so on.
>
>just the ones immediately under .com..  but yes, each zone could have
>its own fuzzy matching rules.

Whoops, I didn't understand you were suggesting that. I *strongly* 
disagree with the notion that an authority gets to have different 
matching rules. It will confuse the hell out of a user who, for 
example, gets one interpretation for foo.gr.com and a different one 
for foo.co.gr and a different one for foo.org.gr. And, as you state 
later, this messes with DNSSEC; we are required not to do that.

>  > >   So root servers
>  > >shouldn't be doing fuzzy matching  for anything except TLDs. (at most)
>  > >(and hopefully we won't need it there)
>  >
>  > But we might. It would be good to make the IDN names equally useful
>  > on all labels, not just non-TLD ones.
>
>I'm assuming that the political barriers associated with defining
>new fuzzy TLDs are the limiting factor here.  It's been hard enough
>to get to the point where we might someday see new non-fuzzy gTLDs.

We already have reasonable proposals for the use of IDN in TLDs, and 
some of those might use the optional characters that we are talking 
about in this discussion.

>though there are certainly interesting issues with fuzzy matching -
>DNSSEC being one (what do you do when the RRs you get back don't
>match the labels you asked for?), and propagation of updates to
>other servers being another (are we going to define a standard format
>for specifying fuzzy matches?)

Don't these two points prevent us from having different kinds of 
normalizing at different points in the DNS?

>on the other hand, with non-fuzzy matches we need to specify
>a set of language-specific "canonicalization" rules for all
>other languages of interest, to go along with the rules we
>already have for ASCII DNS names (case folding, certain characters
>disallowed).

Disagree. No one has said anything about "language-specific" here. If 
uses of the Hebrew *script* have optional characters, and if we 
choose to have a list of optional characters, then the list is of 
10646 code points, regardless of the language that is using them. In 
the case at hand, no one is expected to use Hebrew vowel combining 
marks with any other script. Even if they did, having them be 
optional (or even prohibited) is completely unambiguous.

The nameprep document has no language or other context dependencies.

--Paul Hoffman, Director
--Internet Mail Consortium