Re: iDNR, an alternative name resolution protocol

Jon Davis (jdavis@inetinit.org)
Tue, 1 Sep 1998 14:07:10 -0700


Message-ID: <001201bdd5ec$7cb24d20$637a0118@c603887-a.ptbrg1.sfba.home.com>
From: "Jon Davis" <jdavis@inetinit.org>
To: "URI distribution list" <uri@Bunyip.Com>
Cc: "Sam Sun" <ssun@ns.cnri.reston.va.us>,
Date: Tue, 1 Sep 1998 14:07:10 -0700
Subject: Re: iDNR, an alternative name resolution protocol

>These said, it seems more appropriate to define URI "for representation in
>spoken and written human communication" ONLY. And the URI encoding should
be
>defined as scheme specific. Some URI schemes (e.g. "http:") may require a
>single encoding. While other URI schemes (e.g. "hld:") would allow any
>native encoding to be used. The conversion from the human entered URI to
the
>network protocol is handled by the scheme specific Resolver.


If I may be so naive, arriving at such a late time as this, I would tend to
agree.  I would think we would be shooting ourselves in the foot if we
prematurely created specifications on a broad scale that hindered progress
therein, rather than encouraged it.  Specifically, it is the encoding
limitations described here. Or, in my case, it is the fact that the
acceptable form of a hostname in a URI is defined in the URI rather than
strictly within the scheme used to to dermine the hostname.

On a broader scale, defining limitations with specifications based entirely
on the scope of the technical capabilities of a single period in technology
history is a sad, sad mistake for the IETF.  But then, I may just be naive.

Jon Davis