Re: iDNR, an alternative name resolution protocol

Jon Davis (jdavis@inetinit.org)
Tue, 1 Sep 1998 17:04:21 -0700


Message-ID: <000e01bdd605$3ca3f300$637a0118@c603887-a.ptbrg1.sfba.home.com>
From: "Jon Davis" <jdavis@inetinit.org>
To: "Roy T. Fielding" <fielding@kiwi.ics.uci.edu>
Cc: "URI distribution list" <uri@Bunyip.Com>,
Date: Tue, 1 Sep 1998 17:04:21 -0700
Subject: Re: iDNR, an alternative name resolution protocol 

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

Right.  I understand, you're saying that if you update the spec, existing
implemenations will not be compatible with the updated spec?  But, now, if
the existing spec is too limited to support forward-compatibility to future
adaptations, what can one do, except break the spec?  (You as a group have
probably been through this before, I'm sorry I missed it.)

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

Are you suggesting that in the event a
"thing-that-looks-like-a-URI-wrapped-around-an-iDNR-query"--basically, the
common practice of "breaking the spec"--becomes commonly used and accepted
by the Internet community, it may eventually become a part of the
standardization process of the IETF if it holds itself to be a workable
adaptation to existing specifications?  Even in the event that existing
specifications may have to be edited to incorporate such an adaptation?

Thanks for your patience with me,

Jon Davis