RE: [idn] internal DNS server behavior is irrelevant

["Kenny Huang" <huangk@alum.sinica.edu>]

I support AMC's suggestion. Please stop the irrelevant discussion until
any new draft submitted.


Kenny Huang

> -----Original Message-----
> From: owner-idn@ops.ietf.org [mailto:owner-idn@ops.ietf.org]On 
> Behalf Of Adam M. Costello
> Sent: Thursday, January 24, 2002 1:02 PM
> To: IETF idn working group
> Subject: [idn] internal DNS server behavior is irrelevant
> 
> 
> We can stop discussing what authoritative DNS servers do internally when
> deciding how to answer a query, because it's completely irrelevant.
> An authoritative DNS server is already able to use whatever arbitrary
> method it likes to decide how to answer queries (because it is the
> authority--its answers define the namespace), and the proposed IDNA does
> nothing to change that.
> 
> The only relevant issue is how *other* machines (DNS caching servers and
> end hosts) decide whether two names are the same.  This is the algorithm
> that is used to decide whether a query can be answered from the cache,
> or whether a link has already been visited, or whether the name used
> to contact a web server matches the SSL certificate presented by that
> server.  Because this matching algorithm is performed locally (without
> doing a DNS lookup) it must be well-known and standard.
> 
> Having authoritative name servers do extended matching internally can
> confuse applications (because they effectively create alternate names
> for servers that the servers themselves might not recognize--think
> virtual web hosts).  Getting around this problem would apparently
> entail extending the application servers inside the zone to understand
> the additional matching.  Each zone can decide whether it's worth the
> trouble to go down that road.  But that is all orthogonal to IDNA.
> 
> To reiterate:  We can stop discussing localized matching rules, because
> IDNA does nothing to encourage or prevent them.  The relevant issue is
> the single well-known matching rule.  Can we go ahead with the one in
> IDNA, or do we need to prohibit simplified code points while the TC/SC
> issue is settled (I hope not)?
> 
> AMC