Re: iDNR, an alternative name resolution protocol

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

The existing spec is capable of supporting any functional forward-compatible
extension you might desire, provided that it is encoded in a way that
won't break deployed systems.  You can't break the spec -- it is there to
help you, not to force you to do something.  If you do something outside
of the spec, then you are on your own.

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

Yes, provided it doesn't also have adverse social consequences that
are worse than leaving it non-standard.  That is why it is called a
Draft Standard.

However, thinking up an idea and getting people to implement it are
two entirely different tasks.  Editing the spec is easy compared to
the task of replacing 50 million deployed browser and server applications.

....Roy

Received on Wednesday, 2 September 1998 18:21:11 UTC