Re: iDNR, an alternative name resolution protocol

Roy T. Fielding (
Tue, 01 Sep 1998 15:37:47 -0700

To: Jon Davis <>
cc: URI distribution list <uri@Bunyip.Com>,
In-reply-to: Your message of "Tue, 01 Sep 1998 14:07:10 PDT."
Date: Tue, 01 Sep 1998 15:37:47 -0700
From: "Roy T. Fielding" <>
Message-ID:  <>
Subject: Re: iDNR, an alternative name resolution protocol 

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

Actually, RFC 2396 allows a wide range of syntax options for the
authority part of a URI.  For that matter, a new scheme is not even
required to have an authority part.  The only thing it doesn't allow
is syntax that would break existing parsers, since to do otherwise
would make it impossible to deploy systems that can anticipate extensions
to the namespace.

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

Specifications exist to specify something.  It is rather hard to define
a draft standard for interoperable technology without binding the subject
within the confines of what is interoperable.

Placing an unencoded iDNR in an existing URL won't work.  That is not
because the spec says it is illegal; it is because every deployed parser
on the Internet would puke sideways.  This does not mean you can't use
things-that-look-like-a-URI-wrapped-around-an-iDNR-query within some
date-entry dialogs or protocol elements that expect to find such a
thing *instead* of a URI.  It just means that such things are not URI.

One more thing... The IETF has in no way stated that URI are the one
and only way to identify resources for now and forever.  The only thing
the IETF has done is said that RFC 2396 defines how to interoperably
parse and manipulate the URI of today.