Subject: [idn] iDNS transition: end-system vs. infrastructure?

From: Dave Crocker <[email-masked]>
Date: Mon, 07 May 2001 09:10:43 -0700

Folks,

I've been dogmatically applying the standard view that having to change
only end-systems is  much, much better for transition than having to
change
the infrastructure.  That is why MIME-like encapsulated encoding of the
UTF-8 string makes sense.

The only weakness to such an approach is when it is not possible to do
such
a change.  That is, when it is not possible to limit changes only to
"end
systems". IPv6 is largely an example of needing to change more than
end-systems, namely needing to change infrastructure, except for
IPv6-over-IPv4 tunneling and gatewaying between 6 and 4.  But really,
basic
IPv6 transition is a pure, dual-stack approach.  It does not work unless
and until the infrastructure has been upgraded to support it.  I've been
assuming that iDNS is better using MIME-like encoding than IPv6
dual-stack.

But is it really?

DNS Exchanges are between a client and a true server -- that is, the
entire
transaction is between the DNS client and the DNS server.  The DNS
server
is the real and only target.  By contrast for email, there is a sender
at
one end (email originator) a receiver at the other (email destination)
with
an infrastructure in the middle (SMTP relays).

The DNS infrastructure comprises the DNS servers, I think.  But iDNS
does
not work unless new types of strings are IN THE SERVER.  The "MIME"
model
has been applied on the theory that the server changes are limited to
the
administrative software, which installs an iDNS string into an otherwise
unchanged server.

However it strikes me that having to change a server's administrative
software is no different than having to change some other part of the
server.  That means that iDNS is inherently an infrastructure
transition,
and not really subject to an an end-system transition strategy like
encapsulation.

Let's look at this from another perspective:

There is no problem with a aDNS (old-time ascii DNS) client talking to
an
iDNS server, I assume.  So we can ignore that case.  iDNS client talking
to
iDNS server is even more uninteresting.

So the only interesting case is an iDNS client talking to an aDNS
server.

What is an iDNS client?  It is a user with an iDNS string.

Test 1 (DNS client-side):  If a user enters a UTF-8 string to DNS client
software, what breaks?  That is, if the user with an international
domain
name tries to use client software not ready for it, what happens?

Test 1, tentative answer:  What happens whenever any user tries to use
facilities not supported by their client software?  Bad things.  But
that
is the user's problem to work out with the client software supplier.
This
is no different.  We can therefore, I think, ignore this case,
dismissing
it as "tell the user to upgrade".

Test 2 (DNS server-side):  A user with an iDNS string and an
iDNS-capable
client queries a non-iDNS server.

Test 2, meta-answer:  This is already an error condition; the query is a
mistake.  That is if the server does not support iDNS, then it certainly
won't be holding the entry for the iDNS name that is being
provided.  Hence, querying that DNS server should not be happening!

Test 2, part a:  The UTF-8 shows up at the aDNS server.  The most
important
question is whether the server crashes.  A server that crashes from
malformed input data is a pretty sorry server, but IFF the condition is
prevalent it cannot be ignored.  If the condition is rare, then it can
perhaps be ignored, or treated as less than a showstopper.

Test 2, part b:  If the aDNS server does not crash, does the response
from
the server cause the iDNS *client* to crash?  We can constrain the
problem
by finding out what these responses are, currently, and writing them
into a
client specification.  That should eliminate this factor as a concern.

Test 3:  Client side application-level support for iDNS (the software
that
is the iDNS client's client.)  As with Test 1, this can be ignored by
virtue of being between consenting user and client software provider.

Test 4, parts a and b:  Replicate Test 2 questions, but for
application-level iDNS string servers.  This needs to be sampled around
the
net.  Any substantial amount of server applications crashing (hence Test
4,
part a) is a serious problem, possibly with no clear resolution.

What cases have I missed?

How hard would it be to do some large-scale sampling of deployed servers
around the net?

Summary:

         Users of iDNS currently need revised software.  No matter what
the
technical approach for creating iDNS, users will always need revised
software.  It must be both revised application software and revised DNS
client software.

         Hence, the primary concern for "just do pure UTF-8" is the
effect
of sending UTF-8 to an aDNS server.  However the nature of DNS is such
that
a DNS field with a UTF-8 string only gets sent to a server that is
supposed
to be able to resolve the that field.  With one exception:  The only
time
an aDNS server is likely to get an iDNS query is when the server is
doing
primary support for end-users.  That is, when it is the DNS server that
is
first contact by a client.

d/

----------
Dave Crocker   <mailto:[email-masked]>
Brandenburg InternetWorking   <http://www.brandenburg.com>
tel: +1.408.246.8253;   fax: +1.408.273.6464

---

From: Adonis El Fakih <[email-masked]>
Date: Sat, 12 May 2001 18:06:50 -0400 (EDT)

Hi,

I agree that there are various protocols that will need to be addressed case by case and examine the UTF8, UTF7, UCS2 or ACE solutions.

It would be easier if we can make a list of protocols/applications that will be affected by internationalized domain names (idn).  I feel this would be the first step to make sure we did not skip any protocol/application in the process of evaluating  what is the best solution.

>From the top of my head I can think of
HTTP requests -> DNS
Mail Clients -> SMTP or SMTP-8
Ftp CLients -> ASCII??
News Clients -> NNTP
IMAP CLients -> IMAP
POP CLients -> POP

Although we are looking at what technology to use be it plain UTF8, ACE or something in between, we also need to remember that the protocols we know today will slowly shift to support IDN, and in some cases some will never do. 

I am sorry that I am trying to go to the basics, becuase both UTF8 and ACE solutions seem to be good depending on what apps we are talkign about, so if we define apps/protocols we are trying to make word with IDN, we may also have to introduce a time frame on using one or the other. i.e. it may be that ACE is the best way to implement something now, but then put recommendations forward that all new versions of each protocol should work with UTF8, becasuse ACE also has its drawbacks.  In a way we are trying to map old systems to work with Unicode and future applications, and we want to force the additions of new value added data within the limited scope of 7bit ASCII to be fully backward compliant.

Sorry for the ranting. and Thanks.
Adonis

"Adam M. Costello" <[email-masked]> ßÊÈ:

> Russ Rolfe <[email-masked]> wrote:

> could someone kindly post a simple list of the reasons they feel "Just
> do pure UTF-8" is *not* a valid alternative.

Domain names appearing in message headers, SMTP commands, URIs, etc. are
required by various standards to contain only ASCII letters, digits,
hyphens, and dots.  Therefore there is no telling what existing software
would do if faced with domain names containing other characters.  Some
of it would surely break.  DNS is not the problem.

AMC

______________________________________________________________
Ayna, The Arabic Internet Starts Here.     http://www.ayna.com

---

From: Michael Mealling <[email-masked]>
Date: Mon, 14 May 2001 21:26:53 -0700

On Sat, May 12, 2001 at 06:06:50PM -0400, Adonis El Fakih wrote:
> It would be easier if we can make a list of protocols/applications
> that will be affected by internationalized domain names (idn).  I feel
> this would be the first step to make sure we did not skip any
> protocol/application in the process of evaluating  what is the best
> solution.

Don't forget about the literally hundreds of
proprietary/one-off/in-house
protocols that have been developed over the years that make these exact
same
assumptions. IMHO, you're talking an upgrade for nearly every public and
private protocol on the Internet. IMHO, if you're going to go to that
much of an effort lets instead deploy something new that will fix more
than
20% of the perceived problem space....

-MM

--
------------------------------------------------------------------------
--------
Michael Mealling |      Vote Libertarian!       | www.rwhois.net/michael
Sr. Research Engineer   |   www.ga.lp.org/gwinnett     | ICQ#:
14198821
Network Solutions |          www.lp.org          |  [email-masked]