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

Received on Tuesday, 1 September 1998 20:13:32 UTC