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

[Keith Moore <moore@cs.utk.edu>]

> 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.

Paul, I admit that there are problems with this approach, and one of 
those problems is the possibility for inconsistency between different
zones.  I assume that folks would try to minimize such inconsistencies.
On the other hand, trying to delay iDNS until we understand the
matching rules for every language might not be feasable either.
(and that assumes that we can write rules that don't cause conflicts
between the needs of one language and the needs of another)

I don't think that either you or I are really qualified to state 
whether we need this kind of solution or not.  

> >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.

I have no objection to IDNs in TLDs, I just don't want to see another
political disaster like the gTLD one.

> >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?

I think there are ways of solving both of these problems, but they
would not be fun.  But if we have to formally specify matching rules 
for all languages, we're close to doing the latter anyway.

> >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. 

the rules that we need are language-specific.  if it turns out that
we can write script-specific rules that implement the language-specific
rules without too much conflict between languages, that's a win.
but frankly I'd be surprised if that turned out to be the case.

Keith